Removing class ambiguity without being overly verbose

I have a Java library that I am working on with a directory structure which looks like the following:

/com
  /example
    /LibX
      Server.java
      Client.java

Now, from a project which is using the above classes, it seems to me that importing com.example.LibX.* and using Client client = new Client(...); is a bit ambiguous, as "Client" could mean anything. Therefore, I tried the following, only to receive "package not found" errors:

import com.example.*;

LibX.Client开发者_Python百科 client = new LibX.Client(...);

It is possible to do what I described? Or is there another way to remove the ambiguity without using com.example.LibX.Client?

---

Java packages are not hierarchical, even if they may sometimes look like it. You can't import a "tree" of packages, as you're suggesting. You either need to import a specific package with a wildcard, or you import the specific class name, or you use fully-qualified class names in your code directly.

The following isn't ambiguous, and is considered best practice:

import com.example.LibX.Client;

...

Client client = new Client(...);

In a world where IDEs can organise your imports for you, there's no reason not to state them all explicitly.

---

Your concern about ambiguity is unnecessary - if you have an ambiguous reference your class won't compile - e.g.

import java.util.Date;
import java.sql.Date;

public class Test {

        private Date date;
}

won't compile. So if you can compile the class then by definition you don't have an ambiguous reference.

Incidentally LibX.Client is a bit confusing. Usually classnames are capitalized, package names lowercased, so if you did that (if LibX was a top-level package and you were giving the full name) it looks more like an inner class reference, as in Andy's response above.

---

It's possible if you're willing to group Client and Server as static nested classes.

public class LibX {
  public static class Client {
    //...
  }

  public static class Server {
    //...
  }
}

Now you can import mypak.LibX and then do new LibX.Client(). This has the unfortunate drawbacks of forcing you to group your classes and also creating the additional empty LibX class.

---

There's no such mechanism like what you described. Your only other possibility is to use single class imports:

import com.example.LibX.Client;