Packages and Class Modifiers in Java SE 25
Review package membership, access levels, imports, and the rules for abstract and final classes in Java SE 25.
Can classes declared in one ordinary source file belong to different packages?
Answer: No. An ordinary compilation unit has at most one package declaration, applying to its declared top-level types. Nested classes do not acquire separate package membership. Put types belonging to different packages in separate compilation units.
Source-directory layouts normally mirror package names for tooling, but the package declaration determines membership, not a folder name alone. The javac -d option creates the appropriate package directory structure for generated class files. An import refers to a type; it does not move the current class into that type's package.
Can one source file contain several non-public top-level classes?
Answer: Yes. Several package-access top-level classes can share an ordinary compilation unit. Under normal javac file-based compilation, a public top-level type must match the filename, so there can be at most one such public declaration.
Package-access classes are not private; other code in the same package may access them. Nested classes follow different modifier and access rules. The old claim that only public, abstract, and final can precede a class is incomplete for Java SE 25, which also supports sealed hierarchies and context-specific modifiers.
What are examples of non-access modifiers?
Answer: Examples include abstract, final, static, synchronized, native, transient, and volatile. Each is legal only on appropriate declarations: volatile applies to fields, synchronized can modify methods, and static can modify certain members but not an ordinary top-level class.
Sealed and non-sealed control inheritance in eligible class or interface declarations. Strictfp is a legacy modifier with no effect on modern floating-point evaluation, which has been consistently strict since Java 17. It remains accepted in permitted contexts but can produce a compiler warning. Non-access does not mean unrestricted placement or combination.
Why are there four access levels but only three access-modifier keywords?
Answer: The keywords are public, protected, and private. Package access, often called package-private or default access, is usually expressed by omitting an access modifier on an eligible class member or top-level type.
Default is not an access-modifier keyword. Its use on an interface method supplies an implementation, not package access. Context matters: interface fields are implicitly public, so omission there does not make them package-private. In named-module applications, readability and package exports can further constrain access to public types.
Which access levels are available to an ordinary top-level class?
Answer: Public and package access. Public uses the public keyword; package access omits it. Protected and private are not legal on ordinary top-level class declarations.
Member classes can use additional access levels, so always identify the declaration's nesting context before applying a rule. Local classes have still different restrictions. A public top-level class in a named module is not automatically accessible from every other module: the relevant package must be exported and module-access requirements satisfied.
Must a public class from another package always be imported?
Answer: No. An import permits convenient use of a simple name, but a fully qualified name such as java.util.ArrayList can also be used. Types from java.lang are implicitly imported, and types in the same package normally need no import.
Imports do not grant access to inaccessible types or members, do not recursively import subpackages, and do not add dependencies to the classpath or module path. Java SE 25 also offers module import declarations, but these likewise do not bypass access checks.
When is declaring a class final useful?
Answer: Final prevents subclassing. It is useful when the class is not designed for extension or its invariants should not depend on arbitrary subclass behavior. It also prevents future subclasses from overriding its instance behavior.
Final does not make an object's fields immutable or make its operations thread-safe. Those require separate design decisions. If a controlled set of subtypes is appropriate, a sealed hierarchy may express that requirement more precisely. Composition is another way to support variation without exposing an inheritance contract.
How is an abstract method declared in an abstract class?
Answer: Use the abstract modifier and end the declaration with a semicolon, for example
protected abstract String draw();. There is no method body. A concrete subclass must supply or inherit an implementation satisfying the abstract obligation.public abstract class AbstractLaunch { protected abstract String draw(); private static final class Circle extends AbstractLaunch { @Override protected String draw() { return "Circle"; } } public static void main(String[] args) { AbstractLaunch shape = new Circle(); System.out.println(shape.draw()); } }This prints Circle. The variable's abstract type is valid; the instantiated object is a concrete Circle. The public static main can be launched even though AbstractLaunch itself is abstract.
How is an abstract method changed into an ordinary implemented Java method?
Answer: Remove abstract and replace the terminating semicolon with a valid body. A non-void method must return an appropriate result on normally completing paths, or otherwise satisfy Java's control-flow rules. An empty body is not valid for every return type.
Keep the access, return type, and checked-exception rules compatible with any overridden contract. Supplying one implementation does not necessarily make the surrounding class concrete: it may still have other abstract obligations or deliberately remain abstract. Native method declarations are a separate case with implementation outside ordinary Java source.
Why can a class not be both abstract and final?
Answer: Abstract prevents direct instantiation and allows incomplete behavior to be supplied through subclassing. Final forbids subclassing. Java therefore rejects the combination on a class declaration.
An abstract class need not actually have a subclass merely to compile, and it may contain no abstract methods. It can have constructors, fields, concrete methods, and a static main. A sealed abstract class is legal because sealed restricts which subclasses are permitted rather than forbidding all subclasses.
References: Packages, imports, and compilation units, Class and method modifiers, and Access control.