Lack of understanding with package

[Robert D. Smith]

I am at a loss here, and It has to be some stupid thing I'm overlooking. I've searched the boards, read the Oracle docs, read the Main is a Pain FAQ here... everything looks right to me, but ClientTest fails with the
error: ';' expected
import DSTerm;

Files are located in c:\users\robert\dropbox\java\src\ds\clienttest and ....\ds\dsterm (windows, and yes, I used the proper case when running the compile command)
<cmd prompt> javac -cp C:\Users\Robert\Dropbox\Java\src\DS\ClientTest ClientTest\ClientTest.java

Yes, I am as sharp as a marble. But I can't figure it out.

package dsterm;
import DSTerm;

public final class ClientTest {

    public static void main (string [] args) {
        DSTerm dsterm = new DSTerm();
		string host = "some.host.com";
		int port = 3000;
		
		dsterm.run(host, port);
	}
}

 package dsterm;

public class DSTerm {
	public DSTerm() 
	{
		
	}
	
	void run(String host, int port) 
	{
		System.out.println ("Here Am I.");
	}
}

[Tyson Lindner]

You don't need to import DSTerm its already in the package. Just delete your import statement.

edit: and put them in the same directory

[Stuart A. Burkett]

But if you did want to import the DSTerm class in a class in a different package, the correct statement would be

import dsterm.DSTerm;

The package name is part of the fully qualified class name.

[Robert D. Smith]

Thanks for the replies.

Tyson: The whole point of the exercise is to have them in separate folders. That is the default behavior of eclipse, so it should be doable by hand, which is what I am trying to learn.
Stuart: I tried your suggestion. New error: cannot find symbol <crlf> DSTerm dsterm = new DSTerm(). Seems like progress.

[Tim Holloway]

Assuming that you're adhering to standards (some people are also slow to learn the proper conventions) and DSTerm is a class, the biggest sin in the "import DSTerm;" statement is that you are indicating that the class is part of the Default Package.

Packages are very important in Java, and use of the Default Package is highly discouraged. Some tools will even get annoyed with you. Always put stuff in explicit packages. For example "org.coderanch.myapp.DSTerm".

The full classname of a class consists of the package name plus simple classname, just like the previous example. An import can either be a simple fully-qualified classname or it can be a glob of all classes in a package ("org.coderanch.myapp.*).

In terms of filesystem layout, the class source (and generated class code) follow a directory structure that maps the package structure. Thus you would have something like src/org/coderanch/myapp/DSTerm.java producing classes/org/coderanch/myapp/DSTerm.class. Which, of course, for Windows folks is src\org\coderanch\myapp\DSTerm.java and so forth.

If you run the java compiler directly, you can specify the roots of your source and object (class output) directories. In my example, that would be something like "javac -s src -d classes". It is good practice to not simply compile the sources into the same set of directories as the output classes. For one thing, you can delete the output classes more simply that way when you want to clean up.

When executing a java application, you must provide a classpath. Java makes no assumptions, not even the current directory. So "java -classpath . org.coderanch.myapp.DSTerm" would use the current directory as the class root to execute the main method in the DSTerm class. Or, if you stick to my previous directory structure, that's "java -d classes org.coderanch.myapp.DSTerm". The fully-qualified classname is required, not the simple classname or the filesystem name of the class.

You can use multiple sources (both directories and jars) in your runtime classpath, but the notation is different for Unix-like systems (most of the world) and Windows, since the ":" character is used by Windows as a drive letter indicator and the ";" is used in Unix to stack multiple commands on a line. So the form for Windows is

java -cp .;classes;xyz.jar;C:\myclasses\project1  ...

But for Unix, it's

java -cp .:classes:xyz.jar:/myclasses/project1 ...

Also note that the command-line parser hates spaces (it thinks that they terminate syntactical elements), so "C:\Program Files\myclasses" requires either using quotes around the path or the short-form version of the name (usually PROGRA~1), but it's not predictable - you have to check on the specific machine you're using.

[Tyson Lindner]

Robert D. Smith wrote:
Tyson: The whole point of the exercise is to have them in separate folders. That is the default behavior of eclipse, so it should be doable by hand, which is what I am trying to learn.

Eclipse, at least in the version I have, doesn't even let you compile a hello world program if your package name is different than your folder name.

If your classes must be in different folders, the package for each class should be the name of that folder. Then when you import, as Stuart said you put the folder/package name first, then a dot, then the class. Import doesn't work for using same package but different folders (not something you should be doing anyway).

[Tyson Lindner]

Tim Holloway wrote:
When executing a java application, you must provide a classpath. Java makes no assumptions, not even the current directory. So "java -classpath . org.coderanch.myapp.DSTerm" would use the current directory as the class root to execute the main method in the DSTerm class. Or, if you stick to my previous directory structure, that's "java -d classes org.coderanch.myapp.DSTerm". The fully-qualified classname is required, not the simple classname or the filesystem name of the class.

Not sure what you mean here, java does assume the current directory. If a HelloWorld program is in the current directory you can run it with just:
java HelloWorld

[Tim Holloway]

Tyson Lindner wrote:

Tim Holloway wrote:
When executing a java application, you must provide a classpath. Java makes no assumptions, not even the current directory. So "java -classpath . org.coderanch.myapp.DSTerm" would use the current directory as the class root to execute the main method in the DSTerm class. Or, if you stick to my previous directory structure, that's "java -d classes org.coderanch.myapp.DSTerm". The fully-qualified classname is required, not the simple classname or the filesystem name of the class.

Not sure what you mean here, java does assume the current directory. If a HelloWorld program is in the current directory you can run it with just:
java HelloWorld

Hmmm. I'm pretty sure that didn't used to be true, but current Oracle docs do state that the default classpath is "." (the current directory). One reason why I think it might not always have been that was is that it violates the write-once/run-anywhere presumption of Java. DOS/Windows actually have one "current directory" per logical drive, for example. The "current" current directory being the one on the drive that you've logged to.

I forgot to mention that not only does the directory structure for Java packages have to precisely mirror the package name components, but that even on systems such as Windows where filenames are not case-sensitive to the OS itself, the package directory names must agree in case structure with what's in the actual Java code. So src\com\Coderanch\myapp is not valid for package com.coderanch.myapp, nor is org.apache.camelCase satisfied in src\org\apache\camelcase. That's a general rule in Java filenames anyway, but specifically applies for packages.