Import problem when compiling classes in different packages

Asked

Viewed 223 times

1

I have a problem with import of a package that I created in Java, the project directory tree is this:

.
├── CsvFiles
│   ├── 01
│   ├── 01.zip
│   ├── ALPOO_GRADUACAO_2018.csv
│   ├── ALPOO_GRADUACAO_2019.csv
│   ├── ALPOO_POS_GRADUACAO_2019.csv
│   ├── alunos.csv
│   ├── cursos.csv
│   └── LPOO_GRADUACAO_2019.csv
├── LICENSE
└── src
    ├── entidades
    │   ├── Aluno.class
    │   ├── Aluno.java
    │   ├── Curso.class
    │   ├── Curso.java
    │   ├── Nota.class
    │   ├── Nota.java
    │   ├── Rendimento.class
    │   └── Rendimento.java
    ├── io_handle
    │   ├── handleCSV.java
    │   ├── Menu.class
    │   └── Menu.java
    └── tests
        ├── ALPOO_GRADUACAO_2019.csv
        ├── test.class
        └── test.java


I’m creating a package by directory, for example within entidades, all the files .java has in its first line the code:

package entidades;

In the archive handleCSV.java, I import some classes from the package entidades, and declare his package with the following code:

package io_handle;

import entidades.Nota;
import entidades.Aluno;

But when I compile the Nota.java, get the bug:

╰──➤  javac Nota.java 
Nota.java:3: error: cannot find symbol
import entidades.Aluno;
                ^
  symbol:   class Aluno
  location: package entidades
Nota.java:9: error: cannot find symbol
public class Nota extends Aluno {
                          ^
  symbol: class Aluno
2 errors 

And consequently when I compile handleCSV.java get the bug:

╰──➤  javac handleCSV.java 
handleCSV.java:21: error: package entidades does not exist
import entidades.Nota;
                ^
handleCSV.java:22: error: package entidades does not exist
import entidades.Aluno;
                ^
handleCSV.java:23: error: package entidades does not exist

...

21 errors

But when I compile all the files together with the command:

╰──➤  javac Aluno.java Curso.java Nota.java Rendimento.java 

I don’t get any error. But the error in the build of handleCSV.java continues.

About the files themselves, Curso.java, Aluno.Java, Rendimento.java, handleCSV.java and Menu.java are initiated as follows:

public class [Nome da classe] {
...
}

Already Nota.java is started as follows:

public class Nota extends Aluno {
...
}
  • What is it, Maven? The src is to stay out of the package name. You may have found some way to solve it, but it’s wrong. You have to fix the mistake you made when you weren’t using the src, I don’t know if it’s classpath setting or what.

  • Problem XY. Edit the question by putting the original problem. I voted to close as unclear.

  • Could you check if the Student class is being declared public? in case: public class Student {<Class-content>} Because if not, actually the class reference will not be captured by the compiler.

1 answer

2


Compiling files manually can be good learning to understand how things work, but in practice it’s best to use tools that automate this for you, such as Maven, Gradle, amid others. That said, let’s see how to solve your case.


From the given command lines, it looks like you are entering each folder separately. Instead, go to the project’s root directory and Compile it all at once:

javac -d target/ -sourcepath src/ src/entidades/*java src/io_handle/*java

Or, if you’re using Linux:

javac -d target/ -sourcepath src/ $(find src -name "*.java")

When compiling Nota separately, he will not find the class Aluno because it hasn’t been compiled yet. That’s why it "worked" when you compiled Aluno before. But when compiling handleCSV, as you are in the folder io_handle, it will search for the folder entidades inside io_handle to solve the import's.


To avoid this confusion, simply compile from the root of the project, and then all classes will be searched from the folder indicated by the option sourcepath.

That is, I am at the root of the project and indicated -sourcepath src/, then I am indicating that any class will be searched from src (any class that is in the package entidades will be searched in the folder src/entidades, the same goes for the package io_handle and any other package).

Then you pass the list of files (which can be manually, as in the first option, or using the command find, if you are on Linux, which already searches all the files .java that are in the folder src).

I also used the option -d to indicate the directory in which the files will be placed .class. If I don’t do this, the compiler creates the .class in the same directory as the .java. In which case, I called target (but there is also the custom/convention to call bin or build). My personal opinion is that it is more organized because you do not mix the sources with the compiled files (tools like Maven do this by default).


Not directly related, but try to follow the language naming conventions: classes begin with uppercase letter (HandleCSV instead of handleCSV).

Another point is that it doesn’t seem to make much sense Nota be a subclass of Aluno. A grade is not a specialization of the student, in fact a student may have several grades (it is a case where composition is more appropriate than inheritance). Of course it depends on your requirements, but I can’t imagine a situation where that particular inheritance makes sense.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.