What's wrong with package?
Chen Nan
public class HelloWorld {
public static void main (String[] args) {
System.out.println("Hello World");
}
}
BUT, if I put HelloWorld in a package, it compiles but does not run.
package testbed;
public class HelloWorld {
public static void main (String[] args) {
System.out.println("Hello World");
}
}
My classpath includes the parent directory of \testbed and " . "
(current folder). HELP!!!
Chen
Sauron
Chen Nan wrote in message <37734876...@biotec.or.th>...
Rich Shepard
What does the errror say? What do you type to run your class. I take it
your command line is:
java testbed.HelloWorld
Also you might want to put a constructor on that, something like:
public HelloWorld()
{
}
Even just this fools the JVM that there's a class there, otherwise it
don't work, and it tells you that it can't find the class.
Happy Hunting.
Rich
--
Rich Shepard
http://www.vitesse.demon.co.uk
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Jonathan Moore
testbed\HelloWorld.class?
i.e. the generated class file, not the .java source. Assuming that
you're
not specifying a -d option to javac, then "." should do the trick.
- Are you fully qualifying the name of the class when you try to run it?
i.e. "java testbed.HelloWorld"
If the above are OK, let us know the exact commands you use to compile
and run, and the details of the error you get when trying to run.
Jon Moore
Chen Nan wrote:
>
> My "Hello World" program compiles and runs fine
>
> public class HelloWorld {
> public static void main (String[] args) {
> System.out.println("Hello World");
> }
> }
>
> BUT, if I put HelloWorld in a package, it compiles but does not run.
>
> package testbed;
> public class HelloWorld {
> public static void main (String[] args) {
> System.out.println("Hello World");
> }
> }
>
> My classpath includes the parent directory of \testbed and " . "
> (current folder). HELP!!!
>
> Chen
bret....@engineer.com
> Also you might want to put a constructor on that, something like:
>
> public HelloWorld()
> {
> }
>
> Even just this fools the JVM that there's a class there, otherwise it
> don't work, and it tells you that it can't find the class.
Yeh right! I am sorry to poo poo your response, but I had to chuckle
about your fooling the JVM. Adding a default constructor will have no
effect. In fact there the compiler will create a default constructor
for any class the has no 'user' defined constructors.
Later,
Bret Hansen
Rich Shepard
bret....@engineer.com wrote:
> Yeh right! I am sorry to poo poo your response, but I had to chuckle
> about your fooling the JVM. Adding a default constructor will have no
> effect. In fact there the compiler will create a default constructor
> for any class the has no 'user' defined constructors.
Looks like it's just gonna be one of those days, oh well not long to
go. I had a test compile of it, and what I did I dunno, maybe some
brain aboration, but what I said seemed to make sense *and* work on the
command line, just had another go and you're right.
Sorry fopr giving out bum info:(
Rich
--
Rich Shepard
http://www.vitesse.demon.co.uk
Chen Nan
Thank you for you input.
Jonathan Moore wrote:
> - Does the classpath include the parent directory of
> testbed\HelloWorld.class?
> i.e. the generated class file, not the .java source. Assuming that
> you're
> not specifying a -d option to javac, then "." should do the trick.
>
Yes, both HelloWorld.java and HelloWorld.class are in the \testbed directory
whose parent directory (CoreJavaBook) is in the classpath. I am not great
enough to use any options with with javac yet. Here is all the ugly error
I got
C:\CoreJavaBook\testbed>java HelloWorld
Exception in thread "main" java.lang.NoClassDefFoundError: HelloWorld (wrong
nam
e: testbed/HelloWorld)
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:403)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:101)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:248)
at java.net.URLClassLoader.access$1(URLClassLoader.java:216)
at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:191)
at java.lang.ClassLoader.loadClass(ClassLoader.java:280)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:275)
at java.lang.ClassLoader.loadClass(ClassLoader.java:237)
>
> - Are you fully qualifying the name of the class when you try to run it?
> i.e. "java testbed.HelloWorld"
>
NO. I only entered "java HelloWorld". I just tried your command "java
testbed.HelloWorld" IT WORKED and THANKS! And it works no matter from
which directory I enter it!
However, I still want to learn more. Is it a rule that I have to always
include package name when to run a class in that package? I am learning
Java by using Core Java by Horstmann. In this book, all example programs
are in the default package so the " . " in classpath saves me all troubles.
Then I got a new book "Core Java Foundation Classes" in which, all examples
are in a package, such as package JFCBook.Chapter3, I have not successfully
run a single example from the JFC book because all package related
problems. I use a program called TextPad ( come with the Core Java book) to
compile and run my programs. I like it and do not want give it up.
Chen
NIR
Java testbed.HelloWorld
Chen Nan <che...@biotec.or.th> wrote in message
news:37734876...@biotec.or.th...
Jonathan Moore
> include package name when to run a class in that package? I am learning
> Java by using Core Java by Horstmann. In this book, all example programs
> are in the default package so the " . " in classpath saves me all troubles.
> Then I got a new book "Core Java Foundation Classes" in which, all examples
> are in a package, such as package JFCBook.Chapter3, I have not successfully
> run a single example from the JFC book because all package related
> problems. I use a program called TextPad ( come with the Core Java book) to
> compile and run my programs. I like it and do not want give it up.
>
Yes, you always have to give the package name. It is a fact of life
that there are not enough words available for every class name to be
unique: how many types of package can you think of where it would make
sense to give the main application class the name "Editor"? The package
mechanism in Java (and the namespace mechanism in C++) helps to reduce
the possibility of name conflict.
When your JVM tries to locate a class, it needs to know the fully
qualified name of the class. This is true whether you reference the
class within your own code or at the command-line. In code, you can
give the full class name, e.g. "java.awt.Frame", at every use, or import
the class at the top of the file ("import java.awt.Frame;"), which tells
the compiler what packages to look in when you don't specify the full
class for an object - all references to "Frame" are converted into
"java.awt.Frame". On the command-line, you don't have the equivalent of
an import directive, so you have to give the full class name.
I don't know the book or the program you refer to, but I take it there's
a problem with running packaged classes from the editor. The easiest
solution would be to create your classes in packages, but have a
subclass of the application class at the top-level, which you could then
run:
// In your package
package foo;
class bar {
public static void main(String[] args) {
...
}
}
// At the top level
class runit extends foo.bar {
// no need for any code - main() will get inherited.
}
Having said that, I would be surprised to find such an editor which
didn't let you specify the package somehow.
Jon Moore.
Chen Nan
Chen