I want to use my "Final_Frame.java" in my "SampleFrameProject.java", sort of like interconnecting it by creating a "Final_Frame" object and then typing the "this.show()".
However, an error message appears, saying that "package com.toedter.components does not exist." That is the only error I've seen; I'm confident that my "Final Frame.java" is functioning well before I copy-paste it, hence I knew the issue was caused by my copy-pasting.
Btw all of the error is pointing to JCalender, and JComponents, I'm pretty sure I followed the instructions while installing them. They are working just fine before I move the "Final_Frame.java", but after I move it, it began to show errors. So is there any way for me to copy-paste it correctly? or are there any methods to call "Final_Frame.java" inside my "SampleFrameProject.java" without copy-pasting?
Thank you in advance!
package is a fundamental concept in Java. It is nothing but a namespace for the Java source file, reflecting the directory (folder) structure of your project after the src/main/java directory.
package is usually defined at the first line of the file. For example, given the directory structure from your root directory mavenproject2, the directory structure inside if it is src/main/java/com/foo/bar/FinalJava.java, then the corresponding package defined will be
package com.foo.bar;
// imports
public class FinalJava {
// the content of class
}
For your case, it would seem that you have copied com/toedter/components/FinalFrame.java from the Hotel_Management_System project (which already has defined a line package com.toedter.components in the file) to another project mavenproject2 which has a different directory structure (which is not clear in your question).
The solution would be to modify the package line according to your directory structure then it would solve the error.
Personally, I would suggest to learn some basics in Java, take some tutorials, or at least write some simple Java console applications before diving into GUI applications.
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.
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'm working on creating my own implementation of one of the system Java packages but am having some problems with the wrong class getting picked up when trying to use the package.
For example, lets say my package is: a.b.c.DoStuff and there is an existing Java package with the exact same name, a.b.c.DoStuff.
Using the following code in a test application, I can tell that the system class is still getting used (located in /usr/lib/jvm/java-6-openjdk/jre/lib/rt.jar) instead of my own:
ClassLoader loader = test.class.getClassLoader();
System.out.println(loader.getResource("a.b.c.DoStuff.class");
My package has been compiled into a jar file (package.jar), and I have:
Imported the class in my test file (import a.b.c.DoStuff;)
Added package.jar to my classpath (with both "export CLASSPATH..." and using "java -classpath...")
There must be something I'm overlooking? Any thoughts on how to get my package picked up instead of the system package?
Thanks,
Chris
You can't replace classes from the standard packages unless you put your jar in the special 'endorsed' directory. And some you can't replace at all that way.
Thanks, bmargulies for the tip on the bootclasspath! Prepending my .jar file to the bootclasspath solved my problem. To summarize, I was able to use my own Java package implementation by prepending my package's .jar to the bootclasspath:
java -Xbootclasspath/p:<path-to-jar>
I come from a .NET background and am completely new to Java and am trying to get my head around the Java project structure.
My typical .NET solution structure contains projects that denote logically distinct components, usually named using the format:
MyCompany.SomeApplication.ProjectName
The project name usually equals the root namespace for the project. I might break the namespace down further if it's a large project, but more often than not I see no need to namespace any further.
Now in Java, you have applications consisting of projects, and then you have a new logical level - the package. What is a package? What should it contain? How do you namespace within this App.Project.Package structure? Where do JARs fit into all this? Basically, can someone provide a newbies intro to Java application structure?
Thanks!
Edit: Some really cracking answers thanks guys. A couple of followup questions then:
Do .JAR files contain compiled code? Or just compressed source code files?
Is there a good reason why package names are all lower case?
Can Packages have 'circular dependencies'? In other words, can Package.A use Package.B and vice versa?
Can anyone just show the typical syntax for declaring a class as being in a package and declaring that you wish to reference another package in a class (a using statement maybe?)
"Simple" J2SE projects
As cletus explained, source directory structure is directly equivalent to package structure, and that's essentially built into Java. Everything else is a bit less clear-cut.
A lot of simple projects are organized by hand, so people get to pick a structure they feel OK with. What's often done (and this is also reflected by the structure of projects in Eclipse, a very dominant Java tool) is to have your source tree begin in a directory called src. Your package-less source files would sit directly in src, and your package hierarchy, typically starting with a com directory, would likewise be contained in src. If you CD to the src directory before firing up the javac compiler, your compiled .class files will end up in the same directory structure, with each .class file sitting in the same directory and next to its .java file.
If you have a lot of source and class files, you'll want to separate them out from each other to reduce clutter. Manual and Eclipse organization often place a bin or classes directory parallel to src so the .class files end up in a hierarchy that mirrors that of src.
If your project has a set of .jar files to deliver capability from third-party libraries, then a third directory, typically lib, is placed parallel to src and bin. Everything in lib needs to be put on the classpath for compilation and execution.
Finally, there's a bunch of this and that which is more or less optional:
docs in doc
resources in resources
data in data
configuration in conf...
You get the idea. The compiler doesn't care about these directories, they're just ways for you to organize (or confuse) yourself.
J2EE projects
J2EE is roughly equivalent to ASP.NET, it's a massive (standard) framework for organizing Web applications. While you can develop your code for J2EE projects any way you like, there is a firm standard for the structure that a Web container will expect your application delivered in. And that structure tends to reflect back a bit to the source layout as well.
Here is a page that details project structures for Java projects in general (they don't agree very much with what I wrote above) and for J2EE projects in particular:
http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
Maven projects
Maven is a very versatile project build tool. Personally, my build needs are nicely met by ant, which roughly compares with nmake. Maven, on the other hand, is complete-lifecyle build management with dependency management bolted on. The libs and source for most of the code in the Java world is freely available in the 'net, and maven, if asked nicely, will go crawling it for you and bring home everything your project needs without you needing to even tell it to. It manages a little repository for you, too.
The downside to this highly industrious critter is the fact that it's highly fascist about project structure. You do it the Maven way or not at all. By forcing its standard down your throat, Maven manages to make projects worldwide a bit more similar in structure, easier to manage and easier to build automatically with a minimum of input.
Should you ever opt for Maven, you can stop worrying about project structure, because there can only be one. This is it: http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
A package in Java is very similar to a namespace in .Net. The name of the package essentially creates a path to the classes that live inside it. This path can be thought of as the class's namespace (in .Net terms) because it is the unique identifier for the specific class you want to use. For example if you have a package named:
org.myapp.myProject
And inside it you had a bunch of classes:
MyClass1
MyClass2
To specifically refer to those classes you would use:
org.myapp.myProject.MyClass1
org.myapp.myProject.MyClass2
The only real difference between this and .Net (that I know of) is that Java organizes its "namespaces" structurally (each package is a distinct folder) whereas .Net allows you to scope classes using the namespace keyword and ignores where the document actually lives.
A JAR file is roughly analogous to a DLL in most cases. It is a compressed file (you can open them with 7zip) that contains source code from other projects that can be added as dependencies in your application. Libraries are generally contained in JARs.
The thing to remember about Java is that is is very structural; WHERE files live is important. Of course there is more to the story then what I posted but I think this should get you started.
A package is much like a .Net namespace. The general convention in Java is to use your reversed domain name as a package prefix so if your company is example.com your packages will probably be:
com.example.projectname.etc...
It can be broken down to many levels rather than just one (projectname) but usually one is sufficient.
Inside your project structure classes are usually divided into logical areas: controllers, models, views, etc. It depends on the type of project.
There are two dominant build systems in Java: Ant and Maven.
Ant is basically a domain-specific scripting language and quite flexible but you end up writing a lot of boilerplate stuff yourself (build, deploy, test, etc tasks). It's quick and convenient though.
Maven is more modern and more complete and is worth using (imho). Maven is different to Ant in that Maven declares that this project is a "Web application project" (called an archetype). Once that is declared the directory structure is mandated once you specify your groupId (com.example) and artifactId (project name).
You get a lot of stuff for free this way. The real bonus of Maven is that it manages your project dependencies for you so with a pom.xml (Maven project file) and correctly configured Maven you can give that to someone else (with your source code) and they can build, deploy, test and run your project with libraries being downloaded automatically.
Ant gets something like this with Ivy.
Here are some notes about Java packages that should get you started:
The best practice with Java package names is to use the domain name of the organisation as the start of the package, but in reverse, e.g. if your company owns the domain "bobswidgets.com", you would start your package off with "com.bobswidgets".
The next level down will often be the application or library level, so if it's your ecommerce libraries, it could be something like "com.bobswidgets.ecommerce".
Further down than that often represents the architecture of your application. Classes and interfaces that are core to the project reside in the "root" e.g. com.bobswidgets.ecommerce.InvalidRequestException.
Using packages to subdivide functionality further is common. usually the pattern is to put interfaces and exceptions into whatever the root of the subdivision is and the implementation into sub packages e.g.
com.bobswidgets.ecommerce.payment.PaymentAuthoriser (interface)
com.bobswidgets.ecommerce.payment.PaymentException
com.bobswidgets.ecommerce.payment.paypal.PaypalPaymentAuthoriser (implementation)
This makes it pretty easy to pull the "payment" classes and packages into their own project.
Some other notes:
Java packages are tightly coupled to directory structure. So, within a project, a class with a Package of com.example.MyClass will invariably be in com/example/MyClass.java. This is because when it is packaged up into a Jar, the class file will definitely be in com/example/MyClass.class.
Java packages are loosely coupled to projects. It is quite common that projects will have their own distinct package names e.g. com.bobswidgets.ecommerce for ecommerce, com.bobswidgets.intranet for the intranet project.
Jar files will container the class files that are the result of compiling your .java code into bytecodes. They are just zip files with .jar extension. The root of the Jar file is the root of the namespace hierarchy e.g. com.bobswidgets.ecommerce will be /com/bobswidgets/ecommerce/ in the Jar file. Jar files can also container resources e.g. property files etc.
A package is a grouping of source files that lets them see each others' package-private methods and variables, so that that group of classes can access things in each other that other classes can't.
The expectation is that all java classes have a package that is used to disambiguate them. So if you open a jar file in your project, like spring, every package starts with org.springframework. The classloaders don't know about the jarfile name, they use only the package.
There's a common practice of breaking things down by type of object or function, not everybody agrees about this. Like Cletus posted here, there's a tendency to group web controllers, domain objects, services, and data access objects into their own packages. I think some Domain-Driven Design people do not think this is a good thing. It does have the advantage that typically everything in your package shares the same kind of dependencies (controllers might depend on services and domain objects, services depend on domain objects and data access objects, etc.) so that can be convenient.
Okay so in java you have three different types of access to a classes member functions and variables
public
protected
package-private
and private
All classes in the same package can see each others public, protected, and package-private elements.
Packages are not hierarchical in the system. Usually they are organized in a hierarchical way, but as far as runtime is concerned com.example.widgets is a completely different package from com.example.widgets.cogs
Packages are arranged as directories, which helps keep things organized: your file structure is always similar to your package structure.
They are planning on adding a module system to Java in JDK7 (called Project Jigsaw) and there is an existing module system called OSGi. These module systems will/can give you a lot more flexibility and power then the simple package system.
Also, package names are usually all lower case. :)
To answer the example sub-question:
package com.smotricz.goodfornaught;
import java.util.HashMap;
import javax.swing.*;
public class MyFrame extends JFrame {
private HashMap myMap = new HashMap();
public MyFrame() {
setTitle("My very own frame");
}
}
Do .JAR files contain compiled code? Or just compressed source code files?
They might contain both, or even totally different kinds of files like pictures. It's a zip archive first of all. Most often you would see JARs that contain class files, and those which contain source files (handy for debugging in your IDE if you use third party code) or those that contain javadoc (sourcecode documentatin), also handy if your IDE supports tooltipping the documentation when you access the lib's functions.
Is there a good reason why package names are all lower case?
Yes there is a good reason for package names to be written in lowercase letters: There is a guideline which says that only classnames are written with a capital letter in front.
Can Packages have 'circular dependencies'? In other words, can Package.A use Package.B and vice versa?
Packages do not use each other. Only classes do. And yes that might be possible but bad practice.
Can anyone just show the typical syntax for declaring a class as being in a package and declaring that you wish to reference another package in a class (a using statement maybe?)
Let's assume you want to use the ArrayList class from package java.util, either use
import java.util.ArrayList;
ArrayList myList = new ArrayList();
or use without import (say you use two different classes named ArrayList from different packages)
java.util.ArrayList myList = new java.util.ArrayList();
your.package.ArrayList mySecondList = new your.package.ArrayList();
From Wikipedia:
A Java package is a mechanism for
organizing Java classes into
namespaces
and
Java packages can be stored in
compressed files called JAR files
So for package a.b.c, you could have Java classes in the a, a.b, and a.b.c packages. Generally you group classes inside the same package when they represent related functionality. Functionally, the only difference between classes in the same package and classes in different package is that the default access level for members in Java is "package-protected", which means that other classes in the same package have access.
For a class a.b.c.MyClass, if you want to use MyClass in your project you would import a.b.c.MyClass or, less recommended, import a.b.c.* Also, for MyClass to reside in package a.b.c in the first place, you would declare it in the first line of MyClass.java: package a.b.c;.
To do this you could JAR up the whole package (including packages b and c and class MyClass) and put this JAR into your $CLASSPATH; this would make it accessible for your other source code to use (via the aforementioned import statement).
While it is not as easy to make circular dependent classes work, it may not be impossible. I did get it to work in one case. class A and class B depended on each other and wouldn't compile from scratch. but realizing that a part of class A didn't need class B, and that part was what class B needed to compile completely, I rem'd out that part of class A, not needed by class B, and the remaining part of class A was able to compile, then I was able to compile class B. I was then able to un-rem that section of class A that needed class B, and was able to compile the full class A. Both classes then functioned properly. While it is not typical, if the classes are tied together like this, it is kosher and at times possibly necessary. Just make sure you leave yourself special compile instructions for future updates.