I jsut learned that

A class may be declared with the modifier public, in which case that class is visible to all classes everywhere. If a class has no modifier (the default, also known as package-private), it is visible only within its own package.

This is a clear statement. But this information interfere with my understanding of importing of packages (which easily can be wrong). I thought that importing a package I make classes from the imported package vi开发者_JAVA百科sible to the importing class.

So, how does it work? Are public classes visible to all classes everywhere under condition that the package containing the public class is imported? Or there is not such a condition? What about the package-private classes? They are invisible no mater if the containing package was imported or not?

ADDED: It seems to me that I got 2 answers which are marked as good (up-voted) and which contradict eachother.

Importing a class doesn't change its visibility in any way. Importing a class to another class is more or less just a way to make your source code readable so you don't have to put in fully qualified class all the time. For example this class

import java.util.*;

class ImportTests {
    private Collection collection;
}

compiles to the same code that this class would

class ImportTests {
    private java.util.Collection collection;
}

The import statement in the first class doesn't change the visibility of Collection or any other class inside the java.util package it just makes it so the ImportTests class can reference Collection without the fully qualified name.

You do not need to import a path or a class to make it visible.

To make classes or paths visible, you have to specify at classpath declaration during compilation or execution.

"import" directive ("using" directive in C#) merely helps us to be lazy.

If you have classes

why.does.the.sun.go.on.Shining.java,
rather.be.ahammer.thana.Nail.java,

you could always refer them with their full paths without importing them:

public java.util.Hashtable<rather.be.ahammer.thana.Nail> bornFree(
 java.lang.String shiningKey,
 why.does.the.sun.go.on.Shining shiningPath){

 rather.be.ahammer.thana.Nail nailed =
   new rather.be.ahammer.thana.Nail(shiningPath);
 
 java.util.Hashtable<rather.be.ahammer.thana.Nail> nailedHash =
   new java.util.Hashtable<rather.be.ahammer.thana.Nail>();
 nailedHash.put(shiningKey, nailed);

 return nailedHash;
}

However, laziness being the virtue of creativity, I would rather do

import java.util.Hashtable;
import why.does.the.sun.go.on.Shining.java;
import rather.be.ahammer.thana.Nail.java;

public Hashtable<Nail> bornFree(
 String shiningKey,
 Shining shiningPath){

 Nail nailed =
   new Nail(shiningPath);
 
 HashTable<Nail> nailedHash =
   new Hashtable<Nail>();
 nailedHash.put(shiningKey, nailed);

 return nailedHash;
}

Which, you probably have already realised.

1 - The question would then be,

if there are two classes of the same name but different namespace, which would be used by the compiler?

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

The compiler would complain with error message - conflicting classes for Date
and you would not be able to compile successfully.

So you have to import one of them and use the other with its full path.

In C# we could import

using Dayhawk = hello.day.Hawk;
using Nitehawk = hello.nite.Hawk;

So that we could do,

DayHawk dhawk = new DayHawk(new NiteHawk());

However, either as always, the java authoritarians are either to shy/proud to allow themselves to allow java immitate Microsoft or that Microsoft has a patent on such form of import.

2 - The second question would be,

if we had a class

atlantic.salmon.are.trouts.String.java

Then you did an import

import atlantic.salmon.are.trouts.String;

And when you declare

String salmon = new String();

which String would be used? java.lang.String or atlantic.salmon.are.trouts.String?

The compiler would pick and obey the import statement and use atlantic.salmon.are.trouts.String.

3 - the third issue,

private, protected, public visibility modifiers and default visibility are not to be confused with the import directive at all. Nothing to do except being in the same language.

private references are visible only within the same file.
protected references are visible only within the same namespace packages or by an extension class.
public references are visible to all.
Undeclared, i.e. default, references are visible only within the same namespace packages.

Import directive does not change these behaviours at all.

In conclusion,

The import directive is merely for the continuance of the virtue of laziness.
The import directive is not for the purpose of making classes visible or changing the visibility of their contents.
The classpath argument is for making classes visible to the whole project.
Noting else can change the behaviour of visibility modifiers in a Java compilation.

I have two packages A and C. A has a class named Random in it. My code here compiles fine, and the random is from A and not from java.util. The java.util import gives me a warning in eclipse that the import is unused.

package C;

import A.Random;
import java.util.*;

public class C
{
public static void main(String[] args)
    {
        Random b = new Random();
    }
}

Here is another example of the hiding of classes.

package C;
import java.util.*;
public class C
{
public static void main(String[] args)
    {
        Random b = new Random();
        System.out.println(b.nextDouble());
    }
}

Here is my Random class.

package C;
import java.util.Scanner;

public class Random 
{
private static final long serialVersionUID = 2632389638401709212L;

Scanner s;

public Random()
    {
        super();
        s = new Scanner(System.in);

    }
public double nextDouble()
    {

        System.out.println("Enter your own random number");
        return Double.parseDouble(s.nextLine());            
    }
}

When I run the C main method I get...

Enter your own random number
1
1.0

If you want to use class A from class B, and class B is not in the same package with class A, you must import class B, even if the class B is public.

If public classes didn't need to be imported, there could be no way of declaring two classes with the same name.