Packages and Imports

A single-type import names one class, like import java.util.List;. A wildcard import, like import java.util.*;, lets you use any class from that package. Single imports are clearer and usually preferred.

A package declaration is the first line of code in a Java file, like package com.example.app;. It groups related classes under a name. The folders on disk must match the package name: com.example.app lives in com/example/app/.

String, System, Integer and similar core types live in the package java.lang, which Java imports automatically into every file. So you don't write import java.lang.String; — it's always already available.

You name packages by reversing your organization's internet domain. If your domain is example.com, your packages start with com.example. This makes names globally unique, since domains are unique, so your classes won't clash with anyone else's.

A regular import lets you use a class by its simple name. A static import lets you use a class's static members (fields or methods) by their simple name, without writing the class name first, e.g. just max(a,b) instead of Math.max(a,b).

Java looks for a name in this order of strength: a type in the same package or one you imported by name beats a wildcard import. So a single-type import always wins over *, and a wildcard never overrides an explicitly named type.

You can only import one of them by name. Import one (say import java.util.Date;) and refer to the other by its full name, java.sql.Date, everywhere you use it. There's no syntax to rename an import in Java.

A static import brings a class's static members (methods or fields) into scope so you can call them without the class name — e.g. import static java.lang.Math.PI; lets you write PI instead of Math.PI. Ordinary imports bring in types.

If a Java file has no package line, its class lands in the default (unnamed) package. It works for tiny experiments, but you should avoid it: classes there can't be imported by classes in named packages, and it doesn't scale or organize anything.

Single-member: import static Foo.bar; brings in just bar. Wildcard: import static Foo.*; brings in all of Foo's accessible static members at once. Prefer naming the few members you use; use the wildcard only when you really use many.

Group code by feature or layer with a clear reverse-domain root, keep packages cohesive, and avoid two packages depending on each other (cycles). Use package-private visibility to hide internals so other packages only touch a small public surface.

If two static imports bring in the same simple name and you use it unqualified, the compiler errors as ambiguous and you must qualify the name (write the class). A member in your own class, or an explicit single import, takes priority over a wildcard one and quietly wins.

Static imports make code shorter (max instead of Math.max) but hide where a name comes from. Use them sparingly: for constants you use a lot and for test assertion libraries; otherwise keep the class name so readers know the source.

You can static-import enum constants or named constants so you write SECONDS instead of TimeUnit.SECONDS, or PI instead of Math.PI. Do it only when the name is well-known and the file uses it a lot; otherwise keep the prefix.

An import only tells the compiler how to read a short name. Under the module system (since Java 9), the type's package must also be exported by its module and your module must require that module. Without those, the import fails even if the class exists.