This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
The Package section of the Sun tutorial looks good.
The short answer is we use packages to organize code just like we use folders to organize documents. Large systems can have hundreds or thousands of classes, so careful organization is A Good Thing.
Package structures usually match folder structures on disk or within jar or zip files. When you put "packge x.y.z;" or "import x.y.z.classname;" we expect to find files (source and/or class files) in a folder "x/y/z" relative to one of the locations in the classpath.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Steve De Costa
Joined: Jun 04, 2007
Package structures usually match folder structures on disk or within jar or zip files. When you put "packge x.y.z;" or "import x.y.z.classname;" we expect to find files (source and/or class files) in a folder "x/y/z" relative to one of the locations in the classpath. =====================================================================================
Thanks a lot Stan. Here's the question though. By default, is our folder the workspace we choose or the the project folder created in that workspace (in which our current class is made)?
Also, (with reference to your example), I thought that if our default folder is x, then we should have access to the classes folders y and z since they be folders in x. SO shouldn't we be able to access the class in them wihtout using the package statement? or do we explicitly have to say
Is it possible to include some other folders outside the current workspace? for instance some other classes from folders outside of X even?
Joined: Jan 29, 2003
There are no shortcuts or implied importing of child packages. So you might see:
BTW: the * here is not recommended. Explicitly listing the classes you import is good documentation and avoids certain problems with duplicate class names. I often code * at first and then use Eclipse's refactoring to fix it.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com