Java avoid repeated import (not inherit import)

Question

I've searched and found nothing about this issue that is really bugging:

In every class I make I have to import a whole bunch of files just to be able to use some arbitrary code very often. It's even more annoying as I have to import my own classes over and over, every other one in every of the others, leading to clutter. Just imagine a large project!

With all that Eclipse (it's what I'm using) folding feature and auto-organize, it's a lame ghetto solution. Plus Eclipse can't always say what file to import and I have to look for it and manually add it. So I said I'm too a noob with Java and Eclipse and I must be missing the real way to do it. Please, share it with me.

I've searched and could find questions about "inherit import" but I'm not interested at all in the matter of importing with super/sub classes. What I'm after is to somehow chain-import the files. The matter is simple: if file_b imports from file_a and file_c imports from file_b, I find it of commonsense to think it's redundant to specify file_c imports from file_a.

Better yet, put the ubiquitous code in a file that is silently imported in all the others (like auto-including from a specific path). I repeat: I'm a beginner and I don't know how to do this so please tell me even if it seems very basic.

After all, the compiler can very well put all the code inside one big file but I don't put it myself since the code is way more visually aknowledgeable every class with it's own file.

Thank you in advance.

EDIT: I now have a more clear picture of what's going on:

the package tree is flattened thus a "subpackages" (subfolders) are treated as if on the same level
externals have to be imported in every file, even if in the same package (at all times);
owns don't have to be imported if in the same package (generally);
owns have to be static imported if a own.field is to be used (at all times) so the body of an own class is treated as a new package with respect to the actual class, access-wise.

Thank you all for clarifications. There's useful info from which I've learned new things.

I wish there were these Eclipse features, tho:

actual use the tree structure of packages; if someone makes a subpackage it's because he thinks in terms of dependency. It's a bit of encapsulation principle here. Otherwise the user would put all the packages in the same folder and they would be both more visible and less misleading.
as for the static import, it currently has to be repeatedly specified, breaking the same-package-import-free logic. So make a qualifier like "transparent" for the static class to be imported, that says this class will be by default imported staticly and it will solve the whole problem.

Stephen C · Accepted Answer

I'm afraid that Java is the way it is.

You basically have 3 options:

Use explicit single class imports
Use explicit "star" imports of a classes in a package
Organize the packages so that related classes are in the same package and don't need to be imported.

There is no other "auto-import" or import inclusion mechanism.

I would just point out that most seasoned Java programmers don't share your annoyance. Indeed, most developers just use the facilities provided by the IDE for adding / removing / organizing the imports ... and fold them away by default.

You will get used to it. You have no real alternative.

... it's a lame ghetto solution

Yea, well, you are entitled to your opinion. Most people would just say "it works well enough" ...

For what it is worth, I'm of the opinion that "star" imports (of classes) are a bad idea. Consider this example:

import java.io.*;
import com.other.io.*;  // Some 3rd-party library

public class MyClass {
    ...
    private static File = ...
    ...
}

Suppose that when I develop this code, there is only one File class ... in java.io. But then suppose that a couple of years down the track, th maintainers of the com.other library bring out a new version that defines a new class called com.other.io.File.

If I recompile MyClass against the new version of the library, I will now get compilation errors.
If I don't recompile, I can still run my existing MyClass.class (with the updated library), but my source code will no longer reflect the assumed reality. (In theory, I have to know when the code was compiled to understand what File is referring to.)

Contrast this with an explicit import of java.io.File. That always means exactly what it says, no matter what the 3rd-party library maintainers do.

In short, use of the "star" imports means that someone else can "break" my code by making innocuous and seemingly irrelevant changes to 3rd party libraries. They make my code fragile.

So why did I mention this? Because I think that auto-importing and other attempts at "fixing" Java imports are liable to have the same effect ... only more so!

Java avoid repeated import (not inherit import)

Answers (2)

Related Questions