• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Class not found in Package

 
Steve Stanicki
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello All,
I have a strange problem, and I don't understand why my code is behaving the way it does.

I have my directories as
D:\SCJP\CoreJava\PackageTest.java
and
D:\SCJP\CoreJava\com\mypackagaes\stuff\Employee.java

From the CoreJava directory I did
javac com\mypackages\stuff\Employee.java. It compiles okay.

From CoreJava, I am trying to compile PackageTest.java

The part that puzzles me is:
When I try to compile the PackageTest it errors out saying Employee is a bad class file. .\Employee.java does not contain Employee.

If I comment out the references to Employee in PackageTest, it compiles, so it seems my package statement is ok(?)

If I change the PackageTest.java file import statement from
import com.mypackages.stuff.*; to
import com.mypackages.stuff.Employee; everything runs cool. It compiles and runs as expected.

What am I missing? I thought it would pick up the Employee class with the asterisk, but I need to explicitly name it(!?).

Here are the sources

PackageTest.java:
-----------
import com.mypackages.stuff.*;
//The Employee class is defined in that package

import static java.lang.System.*;

public class PackageTest
{
public static void main(String[] args)
{
//Because of the import statement we don't have to
//use com.mypackages.stuff.Employee here
Employee harry = new Employee("Harry Hacker",50000,1989,10,1);

//Raise salary by 5%
harry.raiseSalary(5);

//Print out info about Harry
//use java.lang.System.out here
out.println("Name: " + harry.getName() + " " + "Salary: " + harry.getSalary());
}
}


Employee.java:
--------------
package com.mypackages.stuff;
//The classes in this file are part of this package

import java.util.*;

public class Employee
{
public Employee(String n, double s, int year, int month, int day)
{
name = n;
salary = s;
GregorianCalendar calendar = new GregorianCalendar(year, month -1, day);
//Gregorian calendar uses 0 for January
hireDate = calendar.getTime();
}

public String getName()
{
return name;
}

public double getSalary()
{
return salary;
}

public Date getHireDay()
{
return hireDate;
}

public void raiseSalary(double byPercent)
{
double raise = salary * byPercent / 100;
salary += raise;
}

private String name;
private double salary;
private Date hireDate;
}

PS: I am working out of Core Java 2 by Cay Horstman page 138.
 
Jesper de Jong
Java Cowboy
Saloon Keeper
Posts: 15205
36
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When I try to compile the PackageTest it errors out saying Employee is a bad class file. .\Employee.java does not contain Employee.

So do you also have a file Employee.java in D:\SCJP\CoreJava ?
What does your CLASSPATH look like?
 
Joanne Neal
Rancher
Posts: 3742
16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I know that you can't call classes in the default package from a class that is in a named package. Is it also the case that you can't call a class in a named package from a class in the default package (which is what is being done here) ?
 
Jesper de Jong
Java Cowboy
Saloon Keeper
Posts: 15205
36
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No, that's not the case.
 
Joanne Neal
Rancher
Posts: 3742
16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thinking about it - you wouldn't be able to use any of the standard java libraries in a default package class if it was the case. Doh!
 
Jody Brown
Ranch Hand
Posts: 43
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"D:\SCJP\CoreJava\com\mypackagaes\stuff\Employee.java"

I assume the typo in "mypackagaes" is an error in the post and not in your actual package structure? I would assume it is the post because you said a fully qualified import works, but I have to point this out anyway.

Is there a reason why you can't do a fully qualified import and not use the wildcard? Are you simply curious as to why it doesnt work using *?

Also, does moving PackageTest to its own package fix the issue? It is usually considered fairly bad practice to use the default package as a dumping ground.

Alas I still cannot see why it doesn't work as you want it yet, I will keep thinking on it.
 
Steve Stanicki
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I had a bunch of extraeneous stuff in my classpath variable set for some directories on my D drive. I got rid of them. They were for some other experiments. I left my classpath pointing at some directories on C only (for MySQL JDBC connector) and it works now.

Because it worked when I named the package name explicitly (without wildcard), I'm assuming the compiler would only look in directories named in the classpath?

Example: If my Windows classpath variable = D:\DirectoryA\SubDirB and you have a package set up as D:\DirectoryA\SubDirZ\source.java; The classpath would override anything to look for classes(?)- that is onlu looking in D:\DirectoryA\SubDirB and ignoring anything else(?)

Steve

PS:Thanks for all of your responses. Your infinite patience is very appreciated.
 
parshuram bingi
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
should your
import com.mypackages.stuff.*;

be
import com.mypackagaes.stuff.*;
???
 
Steve Stanicki
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
BTW mypackagaes is a typo in my original post. It is mypackages in my source code.

But after all the 'extra' paths I had pointing to the D drive were edited out, my code works like the example in the book. (see above).

So I am led to believe that if you are creating packages in a particular path for a particular drive, and you create another package on that particular drive but in a different directory structure, those paths (the new directory structure) will be overriden at compile time by the classpath settings and wont work unless imported explicitly.

Am I understanding this clearly?

Thanks,
Steve
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic