tags:

views:

70

answers:

3

I am creating a project with eclipse, but am unfamiliar with their folder structure. I want to create a folder to keep a bunch of game objects in of a particular type (an attempt at organization), but they extend a class from a different folder... When I try to do this I get errors saying that the class cannot be resolved to a type... If i create the same game object in the folder of the superclass, it works fine...

How do I extend classes from another folder?

How do I create a folder in the workspace view that does not affect the references between folders?

A: 

I'm going to assume this is a Java project in Eclipse; if it's not, please provide more information.

When using classes from within different packages, you need to import them. This is done with one or more import statements at the top of the class file, like so:

import java.util.List;
import java.util.ArrayList;

This tells the compiler, "when I refer to List, I want to use the one that's in the java.util package".

In Eclipse, a convenient way to try and automatically add those import statements is to right-click in the source editor and select "Organize Imports" under "Source". Eclipse will look around all the code and libraries it knows about related to that project and try and resolve any missing imports. If it can't work something out, it'll either prompt you or ignore it. If it finds multiple possibilities, it will usually prompt you to select which one you meant.

For a much more thorough explanation of packages and dividing source code up, please see the Packages lesson in the Java Tutorials.

Rob
The 'packages lesson' is blocked on the computer I'm using (my school blocks java.sun). I am familiar with the 'import' call, but how do I import a class I wrote within the same project? (ie. import ???.Actor;)
Jonathan
What a clever school!
Rob
Agreed. =/In my AP Comp. Sci. class, we need to look at the java documentation, and he can't convince the district to unblock them. =(
Jonathan
Not to drift off-topic, but I suppose you've suggested that he downloads the documentation bundle at home and makes it available on a server somewhere inside the firewall? Better still, get it installed into the JDK directory on each machine so all your IDEs can make use of it!
Rob
Yeah, That has been suggested and done, but it's still frustrating. =/
Jonathan
+1  A: 

I'm assuming you're developing in Java.

Java packages are directly mapped to directories below your source directory replacing . with / (or \ in Windows). If you want to have something like this:

src --+-- dir1 -+-- Foo.java
      |         +---Bar.java
      +   dir2 ---- Baz.java

Then to refer to class Baz in Foo.java you'd use dir2.Baz. As a shortcut, you can add

import dir2.Baz;

at the top of Foo.java and refer to class Baz as just Baz.

Uh Clem
A: 

Too go slightly off on a tangent here, it is also perfectly possible to split the solution up on multiple source folders, but still have them in the same package. It won't make the organization of the source code particularly "organized" or nice, though.

Then each source directory can contain a package named exactly the same (since the directory part of the package name is always relative), and when it is all compiled, they will belong to the same package.

Here's a handy reference.

That would result in something like this

workspace --+-- src1 -- mypackage + -- Foo.java
            |                     + -- Bar.java
            +-- src2 -- mypackage + -- Baz.java

where you can still access all the stuff in the files without explicitly importing them.

Mikael Ohlson