Win a copy of Murach's MySQL this week in the JDBC and Relational Databases forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Package/Classpath problem with 1.4

 
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I've two classes. one class has a package structure and other does not. when i try to compile the class (having package structure) which has a reference to other class (which doesn't have package structure), I get error "cannot resolve symbol"
eg.
****************
package com.hamilsci;
public class A {
public A() {
B obj = new B();
}
}
class A is in dir /usr/local/java/examples
*****************
public class B {
public B() { }
}
class B is in dir /usr/local/java/helperclasses and doesnot have package structure
****************
When I tried to compile A without the package statement, everything works fine. But when I add package structure to Class A, I cannot compile . The error Message is :cannot resolve symbol
symbol : class B
location: class com.hamilsci.A
B obj = new B();
^
I'm using JDK1.4 and I've tried setting the CLASSPATH.
Any help would be highly appreciated.
-Thanks
-Mike
 
Bartender
Posts: 2205
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Two things:
first, your directory structure must match your package hierarchy. If you declare that class A is in package com.hamilsci, then your source file A.java MUST be in a directory tree ./com/hamilsci/A.java.
The "./" in front of com just means that whatever directory the com directory is in, THAT must be in your classpath.
For example, say your com directory is in a directory called foo:
foo/com/hamilsci/A.java
you must include the directory "foo" in your classpath. That way, the compiler and the JVM can location your A.class file in the right package.
Your next problem is that you must understand ALL classes are in a package. The package is the basic unit of organization in a java program. If you don't explicitly include a package statement in your source file, that class gets added to the "default" package.
However, this "default" package should only be used for "hello-world" type applications. If you're going to be creating more than one class for your java app, don't use the default package. You cannot import classes from the default package in jdk1.4, so they're basically useless to you. I would suggest for your program that you put your class B in the same package as class A.
[ March 11, 2002: Message edited by: Rob Ross ]
 
mike seluker
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Rob Ross:
Two things:
first, your directory structure must match your package hierarchy. If you declare that class A is in package com.hamilsci, then your source file A.java MUST be in a directory tree ./com/hamilsci/A.java.
*************
What u r saying is not always true. My dir structure is /usr/local/java/examples/com/hamilsci
And I should have A.java either in /usr/local/java/examples/com/hamilsci or /usr/local/java/examples.
In second case however while compileing I've to use javac -d . A.java
*************
The "./" in front of com just means that whatever directory the com directory is in, THAT must be in your classpath.
********************
CLASSPATH variable contains both the directory structure. I mean i've correct CLASSPATH setting
********************
For example, say your com directory is in a directory called foo:
foo/com/hamilsci/A.java
you must include the directory "foo" in your classpath. That way, the compiler and the JVM can location your A.class file in the right package.
Your next problem is that you must understand ALL classes are in a package. The package is the basic unit of organization in a java program. If you don't explicitly include a package statement in your source file, that class gets added to the "default" package.
However, this "default" package should only be used for "hello-world" type applications. If you're going to be creating more than one class for your java app, don't use the default package. You cannot import classes from the default package in jdk1.4, so they're basically useless to you. I would suggest for your program that you put your class B in the same package as class A.
*****************
Does you mean that from jdk1.4, you CANNOT make use of classes from default package(without package structure). If that's the case I think this limitation will break many people's code. I know its good to use the package sructure but right now we hava already developed an application using classes from default packages. I CANNOT chn that. I've that limitation. I'd appreciate you can suggest any other solution.
***************
[ March 11, 2002: Message edited by: Rob Ross ]

 
Ranch Hand
Posts: 144
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

What u r saying is not always true. My dir structure is /usr/local/java/examples/com/hamilsci


Yes, it is true. The classpath should be pointing to /usr/local/java/examples/ and A.java should be in /usr/local/java/examples/com/hamilsci
You could point your output (using the -d argument) to a directory called something like /usr/local/java/examples/classes but the compiler will then still create a /usr/local/java/examples/classes/com/hamilsci directory.

And I should have A.java either in /usr/local/java/examples/com/hamilsci or /usr/local/java/examples.


No you shouldn't. As Rob suggested your directory structure and your package structure should always match. There may be ways to do otherwise, but that just causes confusion to anyone who would have to read or maintain your code.


In second case however while compileing I've to use javac -d . A.java


The outputted class will still create a directory based upon the package name.

Does you mean that from jdk1.4, you CANNOT make use of classes from default package(without package structure).


Not at all. I think you misunderstood Rob. You can absolutly create and use classes which are not in a package. If you do so then the class that is created must be in a directory which is in your classpath.

If that's the case I think this limitation will break many people's code.


As I've said, that is not a limitation, I think you misunderstood Rob. Let me try to help clear this up with an example.

I have 2 java files. A.java is in package com.foo and B.java is in no package at all. I have a Dev_Projects directory where all my projects go and this particular set of code is in a project called homework1. So I would have a directory structure that looks something like this:
/home/gregb/dev_projects/homework1/src
/home/gregb/dev_projects/homework1/lib
The contents of the /home/gregb/dev_projects/homework1/src directory is
B.java
and
com/foo/A.java
In other words I have
/home/gregb/dev_projects/homework1/src/com/foo/A.java
and
/home/gregb/dev_projects/homework1/src/B.java
Now, I want to keep my source code files separate from my class files. So my source code is under the src directory and I want my compiled class fiels to go under my lib directory. So, I set my classpath to
/home/gregb/dev_projects/homework1/lib
Now, I compile my source code with the -d flag set to /home/gregb/dev_projects/homework1/lib
When I'm done I will have two new class files :
/home/gregb/dev_projects/homework1/lib/B.class
and
/home/gregb/dev_projects/homework1/lib/com/foo/A.class
Since my classpath is set to /home/gregb/dev_projects/homework1/lib this will allow my code to both compile AND to run. Notice that the file that was in a package AND the file that was not in a package are both accessed via the same classpath.
 
mike seluker
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Greg Brouelette:

As I've said, that is not a limitation, I think you misunderstood Rob. Let me try to help clear this up with an example.


what you have said about the location of A.java to in ./com/hamilsci is true for clear understanding. But I can have the A.java in "." directory and then I can compile "javac -d . A.java" which will put the A.class file in "./com/hamilsci". What I am saying that it the A.class file HAS to be in ./com/hamilsci folder not the A.java.
Also about the limitation, you have given a very clear example and that's what my understanding was. This works in jdk1.3 not with jdk1.4. Yesterday I file the BUG to SUN and they have accepted it. Its a new bug in jdk1.4 and the bug id is :4650921. You will be able to see it in BUG database in a day or two.
-cheer
-mike
 
Greg Brouelette
Ranch Hand
Posts: 144
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

"javac -d . A.java" which will put the A.class file in "./com/hamilsci".


Mike: I just want to make sure I understand what you're saying because now it might be "me" that's misunderstanding.
Are you saying that A.java is in the com.hamilsci package BUT it's not in the com/hamilsci directory? Instead it's in the . directory. However, when you compile it you want it placed in the com/hamilsci directory ?
If so then may I ask why? I'm not flaming or anything I just want to know if there is a business case for placing the source files in a directory structure that doesn't match the package structure.
Thanks
 
mike seluker
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Greg Brouelette:

Mike: I just want to make sure I understand what you're saying because now it might be "me" that's misunderstanding.
Are you saying that A.java is in the com.hamilsci package BUT it's not in the com/hamilsci directory? Instead it's in the . directory. However, when you compile it you want it placed in the com/hamilsci directory ?
If so then may I ask why? I'm not flaming or anything I just want to know if there is a business case for placing the source files in a directory structure that doesn't match the package structure.
Thanks


What I'm saying is that There are two places A.java can be present BUT A.class will ALWAYS has to be in com/hamilsci folder. (Remeber A.java contains the following statement
"package com.hamilsci;" )
The first place for A.java is : "." in this case u have to use "javac -d . A.java" and u r issuing this command from "." directory. Here the class file will still be in com/hamilsci folder.
The second place for A.java is: "./com/hamilsci/" In this case u have to use "javac A.java" and u r issuing this command from "./com/hamilsci" folder. Here also the class file will be in "./com/hamilsci" folder.
It purely depend on person where he want to put the java file. Both are acceptable. As far my knowledge I don't see any specific business rule to do that.
I hope I'm clear but if you still have any doubt I'll happy to solve it..
-mike
 
Greg Brouelette
Ranch Hand
Posts: 144
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ah! OK, Then I am understanding you correctly. I agree that the CLASS file must be in the directory that matches the package. But I don't see a reason why you would not want to have your source file in a directory structure that matches the package name.
Now, as I showed in my example earlier, I do place my source code in a "com tree" that is separate from my compiled class "com tree". (source under "src" and classes under "lib") Not having .java and .class files in the same directory makes it very easy to clean up by deleting all the class files and recompile an entire project. So I can understand not wanting to mix your source and compiled files. But it just seems that it's a LOT easier to find your source code , especially in a big project, if the location of your source files also follow the directory structure of their packages.
But I think we're all talking about the same thing now. Thanks. ;-)
 
Rob Ross
Bartender
Posts: 2205
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by mike seluker:
This works in jdk1.3 not with jdk1.4. Yesterday I file the BUG to SUN and they have accepted it. Its a new bug in jdk1.4 and the bug id is :4650921. You will be able to see it in BUG database in a day or two.
-cheer
-mike


ACtually, the bug was with the behavior under 1.3, and it was fixed in 1.4. Your bug has been closed as a duplicate of 4361575, and marked closed&fixed in 1.4
Here's some more info on this subject:


The compiler now rejects import statements that import a type from the unnamed namespace. Previous versions of the compiler would accept such import declarations, even though they were arguably not allowed by the language (because the type name appearing in the import clause is not in scope). The specification is being clarified to state clearly that you cannot have a simple name in an import statement, nor can you import from the unnamed namespace.
To summarize, the syntax
import SimpleName;
is no longer legal. Nor is the syntax
import ClassInUnnamedNamespace.Nested;
which would import a nested class from the unnamed namespace. To fix such problems in your code, move all of the classes from the unnamed namespace into a named namespace.


Full article here: http://java.sun.com/j2se/1.4/compatibility.html#source
(Item #8)
 
mike seluker
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Rob Ross:

Full article here: http://java.sun.com/j2se/1.4/compatibility.html#source
(Item #8)


Yeah I know ,And because these stupid change (which must have broken codes for many), I've to change my whole application which is already in production....
 
reply
    Bookmark Topic Watch Topic
  • New Topic