Public class name same as file name

Why should the public class name be same as the file name in which it is written?
http://forum.java.sun.com/thread.jspa?threadID=198585&messageID=657978
The above thread says it is because it makes the compilation faster. is that the only reason?
Thank you.

That's specified in the JLS. See � 7.6, Top Level Type Declarations.

When packages are stored in a file system (�7.2.1), the host system may
choose to enforce the restriction that it is a compile-time error if a type is not
found in a file under a name composed of the type name plus an extension (such
as .java or .jav) if either of the following is true:
. The type is referred to by code in other compilation units of the package in
which the type is declared.
. The type is declared public (and therefore is potentially accessible from
code in other packages).
This restriction implies that there must be at most one such type per compilation
unit. This restriction makes it easy for a compiler for the Java programming language or an implementation of the Java virtual machine to find a named class
within a package; for example, the source code for a public type
wet.sprocket.Toad would be found in a file Toad.java in the directory wet/
sprocket, and the corresponding object code would be found in the file
Toad.class in the same directory.
When packages are stored in a database (�7.2.2), the host system must not
impose such restrictions.

Similar Messages

Why public class name should be same as the java file name

Hi,
I would like to know, why public class name should be same as the its java file name. Iam in the process of finding the answer to this question. Can someone help me out in finding the explanation.
Thanks in advance,
Manoj

This is a requirement of the Java reference compiler released by Sun. I have used compilers that did not require this, but most seem to follow the reference compiler (which is a very good idea). I am NOT sure if this is specified in the Java Language Specification. Some of the other regulars who are more familiar with the JLS than I may be able to tell you.
? {?

Why File Name is Same Name as The Public Class Name

Hi Friends,
What is the reason for Naming the File Name is puvlic class name??
thanks in advance.

konstkaras wrote:
What could be reason to give it other name?
It's as much better as we have less distinct names.
When I was a schoolboy, I programmed Turbo Pascal. Each program there had a name (declared in file's beginning). The name was never used, but: it has no such restriction of length (as MS-DOS file names had) and it could clash with other identifiers described in code.
So why those names should be distinct?Java was invented after MSDOS was obsolete, so 8.3 limits were not a consideration.
Java is designed for larger programs than were attempted in the MSDOS era, so supports compilation of programs which are created from many source files. Turbo Pascal 4 also supported separate compilation units, and did use the name you mention for exactly that purpose, but I can't remember how it dealt with dependencies between compilation units.
Having the public class' name and package as component in the source file path and the class file path simplifies the dependency problem between the compilation units - all the compiler has to do to determine whether the foo.bar.Baz class needs updating is to look whether foo/bar/Baz.class exists, and if it is less recently modified than foo/bar/Baz.java.

Why it is necessary that public class name should same as filename in java

hi,
why it is necessary that public class name should same as filename in java.
As I know that it is a convention, but I want the information why this convention is made.
thanx.

user13445117 wrote:
but suppose if i am creating a java file with default access modifire then we do not need to save the file name as a class name.So, your question is "Why does the rule about top-level classes being in a file of the same name apply +only+ to public classes"?
If it were applied to all classes, then we could never have two top-level classes in the same file. Doing that is generally not a good idea, but it might be useful from time to time. EJP already told you why it applies to public classes, and, since these are the most common by far, it's a fair compromise that it apply to them but not to other classes.
Was this the reason the original designers did it that way 15 or so years ago? Don't know, don't care, but it's one plausible explanation. Maybe it was just a balance between simplicity and clarity on the one hand, and flexibility on the other.
It's certainly not something I can see caring that much about, unless you're doing an in-depth history on Java, or writing an in-depth treatise on computer language and compiler theory.

Why only one public class in a source file?

why we have to write only one public class in a source file?

PhHein wrote:
Because the JLS says so.It does?
From section 7.6 of the JLS (third edition):
When packages are stored in a file system (§7.2.1), the host system may choose to enforce the restriction that it is a compile-time error if a type is not found in a file under a name composed of the type name plus an extension (such as .java or .jav) if either of the following is true:* The type is referred to by code in other compilation units of the package in which the type is declared.
* The type is declared public (and therefore is potentially accessible from code in other packages).
This restriction implies that there must be at most one such type per compilation unit. This restriction makes it easy for a compiler for the Java programming language or an implementation of the Java virtual machine to find a named class within a package; for example, the source code for a public type wet.sprocket.Toad would be found in a file Toad.java in the directory wet/sprocket, and the corresponding object code would be found in the file Toad.class in the same directory.
>
To my mind, it's strongly recommending, rather than mandating, this practice. All academic of course, merely shifting the answer from "Because the JLS says so" to "Because pretty much all Java compilers say so". I don't know of any that don't enforce this, but of course, that doesn't mean they don't exist

Two public classes in one source file

Can anyone please explain what is the exact reason why the java source file name should be same as the only allowed public class name in the source file. Answer only if you know the correct answer. No gusses please. I read the other postings on this topic. None of the answers were correct.

One reason is that some RISC processor architectures
(like those Sun uses mostly) have hierarchical memory
architectures. This hierarchy is divided into global
modules and local (global-accessible) submodules. The
advantage of this is that the processor needs lesser
memory access "points" (handles), as the modules
delegate CPU calls to the submodules.
The java compiler can utilize this and increase
performance by loading the entire source files into
the memory and assign them a CPU handle (the module
ID). It'll be later used for linking, e.g. The public
class in a file will be loaded as a module and gets
the handle, all other non-public classes in that file
will be submodules.
If there is no public class, a generic module will be
used, so that's no problem. But if there are multiple
public classes, you'd end up with several modules and
just one handle to assign, thus having ambiguity. The
CPU won't be able to address the correct module.
This all only applies to RISC CPUs, but for obviuos
cross-platform compatibility reasons it was added to
the standard - it doesn't hurt the other
architectures, but helps those with hierarchical
memory management.Thanks, but the rooster explanation makes more sense to me.
Now could someone please express it a la Majinda?

If you have two public class in a java file what will be the error ?

Q:If you have two public class in a java file what will be the error and how will you remove that.?

Kannan_S wrote:
I dont want you to be on that list . Here goes my explanation..
A class is well defined with members and functions
An abstract class is not defined well as compared to a full fledged class (talking more generically)
An interface is more abstract.
I was asking the author who has posted this question to be like a class(very clear)
and not either as an abstract class or an interface
Hope i have made it clear..Not in the slightest. This has absolutely no bearing whatsoever on the question asked. Not to mention that classes are classes, and all equal in the eyes of the compiler, be they abstract, concrete or interfaces. It's difficult to see what your point is, to be honest, but I suspect it wouldn't be worth seeing anyway

Why a public class name and file name same?

All of us know that, a public class should be declared in a file which has the same name of that class. What is the underlying concept behind this..Can someone give a clear explanation?
Thanx..
Sandeep Joseph
Paragon Solutions
[email protected]

Another issue, it was said that the file must be named
after the class to find the class's code when
compiling dependent classes. Doesn't this apply to
non-public classes too (with the dependent class being
located in the same package)?This applies to all top-level classes ...
You can define multiple classes in one file though:
class A {
class B {
}It's perfectly valid to have both classes defined in the same file (named A.java if A is the first class to be defined in that file).
You will get a compiler warning as soon as you reference a non-top-level class from a class that is defined in another file, though.

Why the name of our source file should be same as the 'public class' name

Hi all,
I am very new in java and have a question in my mind.
I read somewhere , our souce file name should be same as public class in that file.
but i don't know the reason for this.
Can anybody help me out with this .
Thanks,

HMRPanchal wrote:
Thanks,
Can you give me some link or documents from where I can go through this article.
because I am not clear with what you are saying( makefiles , automatic recompilation etc).
I am a new in Java .The fact that you don't have to worry about those things is what makes it A Good Thing.

Public class name same as filename

Every book I've read stated that if you have a public class declared in the source file, then you have to name the file the same as the class name. However, none of the book explain why, can anyone tell me about this?

Not all public classes need to have the same name as the file that contains them -- only top-level public classes. Public nested classes can have a name that's different from the filename.
Also, not only do top-level public classes need to have the same name as the file that contains them, but the names of the package and the directory structure must match as well.
This is done simply so that if you see a class named com.mycompany.mypackage.MyClass referred to somewhere, you know that the source code is in the file com/mycompany/mypackage/MyClass.java. Isn't that helpful? ;-)

Why we can have only one public class in one source file

why we can have only one public class in one source file

When the java compiler is run it looks for classes referenced by the classes you are directly compiling. When looking for these referenced classes it looks for source as well as class files and compiles them automatically if the coresponding class files are missing, or older than the source.
In order to do this it must be able to work out the source file name for any given class which might be referenced from another (the rule also applies to package level access).

"Name Clash: Method in Two Classes Have Same Erasure, Yet Neither Over-..."

Ok, I'm getting this message when trying to compile the classes below: "FileUtils.java:1117: name clash: add(E) in java.util.ArrayList<java.util.LinkedList<F>> and add(T) in gov.sandia.gajanik.util.Addable<F> have the same erasure, yet neither overrides the other"
The funny thing is, they actually don't have the same erasure, from what I can see. In short, I have a class
class DuplicatesArrayList<F extends File> extends ArrayList<LinkedList<F>> implements Addable<F>Addable<T> has a method
public boolean add(T addMe);and, from the javadoc for jdk1.6.0, ArrayList<E>has a method
public boolean add(E e);But, note how ArrayList has the type parameter LinkedList<F> and Addable has the type parameter F. Given that, the erasures should be
public boolean add(LinkedList e);//Erasure of LinkedList<F>
public boolean add(File addMe); //Erasure of FAm I missing something? Is it just the end of the day and my brain isn't working right? Help!

Actually, the ArrayList extension is the most critical part. The class I'm trying to make really is an ArrayList that has files added to it, but stores them in LinkedList (the context doing the adding decides when to delimit the files in LinkedLists). I came to this solution because I tried to designed the method that's actually using the ArrayList the take anything that it can "add" Files to and separate related groups of files. This way it can either use a collection-type class (what you've seen here) or a class that handles the files differently (I have one that prints them to System.out instead). I could require a collection, but then the method that is calling "add" also has to specify exactly how it groups related files together (which is less flexible), and callers must implement all the methods specified by the Collection interface (or have them throw something like an UnsupportedOperationException for everthing except "add"), even though all I need is "add".
I probably could make my own inheritance tree that would simply be a copy of that in java.util, starting at AbstractList. But I have qualms about copying Sun's source code (which is essentially what I would do) and then just add the few methods I need to their collection classes.
I'm interested to know how you would implement such a solution, if you would be kind enough to show me. Here's what I have:
* An interface that specifies an object that can have things added to (and thus
* processed by) it.
* @param <T> The type processed by this {@code Addable}
public interface Addable<T> {
 * Ensures that this {@code Addable} takes appropriate action on the
 * specified object
 * @param addMe The object to operate on
 * @return Whether or not the operation succeeded
 public boolean add(T addMe);
 * Ensures that this {@code Addable} takes appropriate action on all the
 * items returned by the iterator of the specified iterable object
 * @param itr The object to get items from
 * @return The number of items successfully proccessed
 public int addAll(Iterable<T> itr);
 public static final class DefaultBehavior {
 * Ensures that this {@code Addable} takes appropriate action on all the
 * items returned by the iterator of the specified iterable object
 * @param <T> The type contained by the iterator and target
 * @param me The target to add to (typically the caller)
 * @param itr The object to get items from
 * @return The number of items successfully proccessed
 public static final <T> int addAll(final Addable<T> me,
 final Iterable<T> itr) {
 int totalAdded = 0;
 if (itr instanceof List) {
 for (T element : (List<T>)itr)
 if (me.add(element))
 totalAdded++;
 } else {
 for (T element : itr)
 if (me.add(element))
 totalAdded++;
 return totalAdded;
}I would make Addable an abstract class with that default implementation for addAll, but alas, Java only allows single class inheritance, and I can't even make that DefaultBehavior class protected (which would make more sense than public).
* @param <T> {@inheritDoc}
public interface GroupingAddable<T> extends Addable<T> {
 * Indicates the items added since the last call to this method should be
 * associated under the given combination of keys
 * @param keys The keys that identify this group
 * @return The number of items that were added to the group
 public int group(Object... keys);
 * Supplies some default implementations of the methods in this interface
 * 
 * This member would be more suited to {@code static protected} access, but
 * the JLS does not allow protected members of interfaces.
 public static class DefaultBehavior {
 * Ensures that this {@code Addable} takes appropriate action on all the
 * items returned by the iterator of the specified iterable object
 * @param <F> The type contained by the iterator and target
 * @param me The target to add to (typically the caller)
 * @param itr The object to get items from
 * @return The number of items successfully proccessed
 public static final <F extends File> int addAll(
 final DuplicatesStore<F> me,
 final Iterable<F> itr) {
 int totalAdded = 0;
 if (itr instanceof List) {
 for (F element : (List<F>)itr)
 if (me.add(element))
 totalAdded++;
 } else {
 for (F element : itr)
 if (me.add(element))
 totalAdded++;
 return totalAdded;
 * Wraps a given {@code DuplicatesStore} in a
 * {@link GroupingAddable} that passes calls to the given store
 * @param <F> The type accepted by the given store
 * @param store The object to wrap
 * @return An {@code Addable} wrapper for the given store
 public static final <F extends File> GroupingAddable<F>
 asGroupingAddable(final DuplicatesStore<F> store) {
 return new GroupingAddable<F>() {
 public int group(Object... keys) {
 return store.group(keys);
 public boolean add(F addMe) {
 return store.add(addMe);
 public int addAll(Iterable<F> itr) {
 return store.addAll(itr);
 protected DefaultBehavior() {
 throw new UnsupportedOperationException("Class has no instance members");
}Note that the following class exposes the same public API as GroupingAddable, but the aforementioned name clash requires this copy
public interface DuplicatesStore<F extends File> {
 * Adds a duplicate to the current group of duplicates
 * @param addMe The duplicate to add to the current group of duplicates
 * @return true if the add operation succeeded, false otherwise
 public boolean add(F addMe);
 * Ensures that this {@code Addable} takes appropriate action on all the
 * items returned by the iterator of the specified iterable object
 * @param itr The object to get items from
 * @return The number of items successfully proccessed
 public int addAll(Iterable<F> itr);
 * Marks the previous file {@code add}ed as the last of a group of files
 * that are duplicates.
 * @param keys Ignored
 * @return The number of files in the group that was just marked
 public int group(Object... keys);
 * Supplies some default implementations of the methods in this interface
 * 
 * This member would be more suited to {@code static protected} access, but
 * the JLS does not allow protected members of interfaces.
 public static class DefaultBehavior {
 * Ensures that this {@code Addable} takes appropriate action on all the
 * items returned by the iterator of the specified iterable object
 * @param <F> The type contained by the iterator and target
 * @param me The target to add to (typically the caller)
 * @param itr The object to get items from
 * @return The number of items successfully proccessed
 public static final <F extends File> int addAll(
 final DuplicatesStore<F> me,
 final Iterable<F> itr) {
 int totalAdded = 0;
 if (itr instanceof List) {
 for (F element : (List<F>)itr)
 if (me.add(element))
 totalAdded++;
 } else {
 for (F element : itr)
 if (me.add(element))
 totalAdded++;
 return totalAdded;
 * Wraps a given {@code DuplicatesStore} in a
 * {@link GroupingAddable} that passes calls to the given store
 * @param <F> The type accepted by the given store
 * @param store The object to wrap
 * @return An {@code Addable} wrapper for the given store
 public static final <F extends File> GroupingAddable<F>
 asGroupingAddable(final DuplicatesStore<F> store) {
 return new GroupingAddable<F>() {
 public int group(Object... keys) {
 return store.group(keys);
 public boolean add(F addMe) {
 return store.add(addMe);
 public int addAll(Iterable<F> itr) {
 return store.addAll(itr);
 protected DefaultBehavior() {
 throw new UnsupportedOperationException("Class has no instance members");
}And we're getting closer to an actual implementation. I have both a LinkedList and ArrayList implementation of this interface, but I'm only posting the ArrayList. This would also be a good candidate for an abstract class, but then I wouldn' be able to inherit from java.util classes. The methods specified by this interface have the same implenation in both the ArrayList and LinkedList versions.
* A list of {@link LinkedList} specically for storing and grouping
* duplicate files
* @param <F> The type contained by this list
public interface DuplicatesList<F extends File> extends List<LinkedList<F>>,
 DuplicatesStore<F> {
 * Adds a duplicate to the current group of duplicates
 * @param file The duplicate to add to the current group of duplicates
 * @return true if the add operation succeeded, false otherwise
 public boolean add(F file);
 * Marks the previous file {@code add}ed as the last of a group of files
 * that are duplicates.
 * @param keys Ignored
 * @return The number of files in the group that was just marked
 public int group(Object... keys);
 * Retreives the number of files added to this collection.
 * 
 * This is not the number of collections contained immediately within
 * this collection, but the count of all files contained in this
 * collection's collections
 * @return The count of files contained
 public int records();
 * {@inheritDoc}
 * @param <F> The type contained by the object that contains an instance of
 * this class
 public class DefaultBehavior<F extends File> extends
 DuplicatesStore.DefaultBehavior {
 * Temporary storage for duplicate files until {@code group} is called,
 * at which point this variable is added to {@code this}, then cleared
 protected LinkedList<F> innerStore = new LinkedList<F>();
 /** The number of files added to {@code this} */
 protected int records = 0;
 protected DefaultBehavior() {
 * Adds a duplicate to the current group of duplicates
 * @param me Ignored
 * @param file The duplicate to add to the current group of duplicates
 * @return true if the add operation succeeded, false otherwise
 public final boolean add(DuplicatesList<F> me, final F file) {
 records++;
 return innerStore.add(file);
 * Marks the previous file {@code add}ed as the last of a group of files
 * that are duplicates.
 * This particular implementation will remove the first element added to
 * the group, sort the group according to its natural order, add the
 * element that was removed to the beginning of the group, then add the
 * linked list representing the group to this {@code LinkedList}.
 * @param me The object to operate on (typically "this")
 * @param keys Ignored
 * @return The number of files in the group that was just marked
 public final int group(final DuplicatesList<F> me,
 final Object... keys) {
 int innerSize = innerStore.size();
 if (innerSize > 1) {
 F base = innerStore.pop();
 sort(innerStore);
 innerStore.addLast(base);
 if (me.add(innerStore)) {
 innerStore = new LinkedList<F>();
 return innerSize;
 } else return -1;
}And the implentation
* An {@code ArrayList} implementation of {@link DuplicatesList}
* 
* Groups are contained in {@code LinkedList}s stored within this
* {@code ArrayList}.
* @param <F> {@inheritDoc}
public class DuplicatesArrayList<F extends File>
 extends ArrayList<LinkedList<F>> implements DuplicatesList<F> {
 * Constructs a list containing the elements of the specified
 * collection, in the order they are returned by the collection's
 * iterator
 * 
 * (Documentation copied from {@link ArrayList})
 * @param addMe The collection whose elements are to be placed into this
 * list
 * @throws NullPointerException If the specified collection is null
 protected DuplicatesArrayList(Collection<? extends LinkedList<F>> addMe) {
 super(addMe);
 def.records = super.size();
 * {@inheritDoc}
 * @param itr {@inheritDoc}
 * @return {@inheritDoc}
 @SuppressWarnings("static-access")
 public int addAll(Iterable<F> itr) {
 return def.addAll(this, itr);
 * {@inheritDoc}
 * @param file {@inheritDoc}
 * @return {@inheritDoc}
 public boolean add(F file) {
 return def.add(this, file);
 * {@inheritDoc}
 * 
 * This particular implementation will remove the first element added to
 * the group, sort the group according to its natural order, add the
 * element that was removed to the beginning of the group, then add the
 * linked list representing the group to this {@code ArrayList}.
 * @param keys {@inheritDoc}
 * @return {@inheritDoc}
 public int group(Object... keys) {
 return def.group(this, keys);
 * {@inheritDoc}
 * @return {@inheritDoc}
 public int records() {
 return def.records;
}Here's an alternative to the collection-type DuplicatesStore I just showed you
* An object that prints duplicates as they are grouped
* 
* The first file added to the group is appended to the {@link Appendable}
* provided at construction. If specified at construction time, the system-
* specific path separator (as specified by {@link File#pathSeparator} then
* the file's length are also appended. Then the previous text is followed
* by the system line separator (as specified by
* {@code System.getProperty("line.separator")}). Any files
* that were added after it are appended in the same way, but are preceded
* by a horizontal tab, are not followed by their length.
public class PrintingDuplicatesStore
 implements DuplicatesStore<File>, GroupingAddable<File> {
 * The system-specific line separator
 public static final String LINE_SEPARATOR =
 System.getProperty("line.separator");
 * The exception that contains any uncaught {@code Throwable}s thrown
 * during a call to {@code group} or {@code add}
 public static class AppendException extends RuntimeException {
 * Creates a new AppendException with it's cause set to the given
 * {@code Throwable} and messages set to the parameter's messages
 * @param cause The {@code Throwable} that caused this
 * {@code AppendException} to be thrown
 public AppendException(final Throwable cause) {
 super(cause);
 * {@inheritDoc}
 * @return {@inheritDoc}
 public String getMessage() {
 return getCause().getMessage();
 * {@inheritDoc}
 * @return {@inheritDoc}
 public String getLocalizedMessage() {
 return getCause().getMessage();
 * This object to send output to
 protected Appendable out;
 * Whether this object is appending unique files (files in a group that
 * was only added to once) to the output
 protected boolean printingUniques;
 * Whether this object is appending files that have copies (groups with
 * more than one file) to the output
 protected boolean printingCopies;
 * Whether this object appends a path separator and the file's length
 * to the output after the first file of a group is appended
 protected boolean printingLength;
 /**The first file addded to the current group (null if the group is new)
 protected File currentBase = null;
 /** The number of files in the current group*/
 protected int groupSize = 0;
 * Creates a new instance whose behavior is specified by the given
 * parameters
 * @param out The output to append to
 * @param printUniques Specifies if this object should append unique
 * files
 * @param printCopies Specifies if this object should append files that
 * have copies
 * @param printLength Specifies if this object should append the lengths
 * of the files in a goup
 public PrintingDuplicatesStore(final Appendable out,
 final boolean printUniques, final boolean printCopies,
 final boolean printLength) {
 this.out = out;
 this.printingUniques = printUniques;
 this.printingCopies = printCopies;
 this.printingLength = printLength;
 * Add a file to the current group
 * @param addMe The file to add
 * @return {@code true} always
 * @throws AppendException if an IOException occurs whilst attempting to
 * append to the output. The AppendException's cause is set to
 * the IOException that was thrown.
 public boolean add(final File addMe) {
 try {
 if (currentBase == null) {
 currentBase = addMe;
 groupSize++;
 } else
 if (printingCopies) {
 out.append(addMe.toString());
 groupSize++;
 return true;
 } catch (final IOException ioe) {
 throw new AppendException(ioe);
 * Appends the file paths added since the last call to this method to
 * the output designated at construction
 * @param keys Ignored
 * @return The number of files added between the last call and this call
 * to this method
 * @throws AppendException if an IOException occurs whilst attempting to
 * append to the output. The AppendException's cause is set to
 * the IOException that was thrown.
 public int group(final Object... keys) {
 try {
 if (groupSize == 1 && printingUniques)
 appendBase(currentBase);
 } catch (IOException ioe) {
 throw new AppendException(ioe);
 int rv = groupSize;
 groupSize = 0;
 return rv;
 * Called to append the base file to the output (follow the file name
 * with a path separator, a space, and the file's length, if neccessary)
 * 
 * @param base The file to add that is the base file for the group
 * @throws IOException If an IOException occurs whilst attempting to
 * append to the output
 protected void appendBase(final File base) throws IOException {
 out.append(base.toString());
 if (printingLength)
 out.append(File.pathSeparator).append(" ")
 .append(Long.toString(base.length()));
 out.append(LINE_SEPARATOR);
 * {@inheritDoc}
 * @param itr {@inheritDoc}
 * @return {@inheritDoc}
 public int addAll(final Iterable<File> itr) {
 return GroupingAddable.DefaultBehavior.addAll(this, itr);
* An object that prints duplicates, in order, as they are grouped
* 
* The only difference between this and its superclass is that this removes
* and prints the first element in the group, then sorts the remaining
* elements before printing them.
public class SortPrintingDuplicatesStore extends PrintingDuplicatesStore {
 /** Temporary storage for the current group */
 LinkedList<File> duplicates = new LinkedList<File>();
 * Creates a new instance whose behavior is specified by the given
 * parameters
 * @param out The output to append to
 * @param printUniques Specifies if this object should append unique
 * files
 * @param printCopies Specifies if this object should append files that
 * have copies
 * @param printLength Specifies if this object should append the lengths
 * of the files in a goup
 public SortPrintingDuplicatesStore(final Appendable out,
 final boolean printUniques, final boolean printCopies,
 final boolean printLength) {
 super(out, printUniques, printCopies, printLength);
 * {@inheritDoc}
 * @param addMe {@inheritDoc}
 * @return {@inheritDoc}
 public boolean add(File addMe) {
 return duplicates.add(addMe);
 * {@inheritDoc}
 * @param keys {@inheritDoc}
 * @return {@inheritDoc}
 public int group(Object... keys) {
 try {
 groupSize = duplicates.size();
 if (groupSize > 1)
 if (printingCopies) {
 appendBase(duplicates.pop());
 sort(duplicates);
 while (duplicates.size() > 0)
 out.append("\t")
 .append(duplicates.pop().toString())
 .append(LINE_SEPARATOR);
 return groupSize;
 } else
 duplicates = new LinkedList<File>();
 else
 if (printingUniques)
 appendBase(duplicates.pop());
 return groupSize;
 } catch (IOException ioe) {
 throw new AppendException(ioe);
}And the method that spawned all those interfaces and classes above
* Find identical files.
* 
* Functions like {@code getDuplicates(bases, order, exceptions, subjects)},
* except that files in {@code subjects} that are found to be duplicates of
* files in {@code bases} are added to the given {@code store} instead of
* returned.
* 
* If {@code bases} is not null, then the first file added to {@code store}
* after each call to {@link DuplicatesStore#group} is from {@code bases}.
* 
* @param <F> The desired type the returned collection should contain. It
* must be {@link File} or a subtype, and all elements in both
* {@code bases} and {@code subjects} must be assignable to it.
* @param bases The only files to look for duplicates of
* @param order A comparator to apply to files
* @param exceptions The collection to add exceptions to, if they occur
* @param store The collection to store duplicate files in
* @param subjects The files to search for duplicates in. Must implement
* hasNext, next, hasPrevious, previous, and remove
* @see #getDuplicates(Collection, Comparator, Collection, ListIterator)
public static final <F extends File> void getDuplicates(
 final Collection<? extends F> bases, final Comparator<File> order,
 final Collection<? super IOException> exceptions,
 final GroupingAddable<? super F> store,
 final ListIterator<? extends F> subjects) {...}

Only one public class - why???

Hi
I have come across this statement many places -
"There can be only one Top-Level 'public' class in
a java source file which should have same name as that
of the fore mentioned class."
I know that the compiler searches for the class
with same name as that of the file that is passed to
the compiler.I am also aware that a Java source compiles
smoothly with One or None Top-Level 'public' class,
but I fail to comprehend this -
Why can there be only one TOP-LEVEL 'public' class
in a Java Source file?
The importance of 'TOP-LEVEL' is as important as
any thing else, as you yourself check that a Nested
class within an Enclosing class can be 'public' along
with someother Top-Level 'public' class in the program
compiles smoothly unlike having TWO Top-Level 'public'
classes in same file.
I have found no reason supporting this statement in any
of the refernces I have checked out.Ppl I have asked told
me that it is so coz Java Spec say so.
Is there an better answer to my question?
Thanx in advance, appretiate it.
Regards
Pradeepto

I have found no reason supporting this statement in
in any
of the refernces I have checked out.Ppl I have asked
told
me that it is so coz Java Spec say so.I can tell you that anybody who says its because the Java spec says so, is wrong - the Java spec does not say so.
It is a limitation of Sun's javac compiler, which many other compilers exhibit as well. I don't know the full formal reasoning behind it (and would be interested in knowing if you find a good answer), but I assume it simply has to do with finding classes without having to load everything on your classpath.
Whether other compilers are purposely acting the same way as javac, or whether it is some sort of performance optimisation that most vendors feel is worthwhile, I couldn't say.
I don't see what you're saying about top-level and nested classes. Although you can declare a public nested class inside a non-public top-level class, the nested class is not actually publicly visible, by virue of its enclosing class not being publicly visible.

Public class question

I want to know what is the logic behind saving only one public class in one .java file. and why public class is saved with the same name.
thanks for consideration

If you're new to a large project with many classes and your assigned to make a modification to class X then where do you find this code.
If you know that class X is in the file X.java then its easy to find.
C++ is a pain for this, IDE's like visual studio will normally follow the same rules but allows the programmer to break those rules if he wishes.
Java is stricter keeping code more consistent.

Java Public classes

Can somebody tell me why do we need to defined java public classes in a seprate file ??

because the specifications tell you too.As jschell has mentioned, the spec doesn't explicitly say. I read this:
When packages are stored in a file system (�7.2.1), the host system may choose to enforce the restriction that it is a compile-time error if a type is not found in a file under a name composed of the type name plus an extension (such as .java or .jav) if either of the following is true:
* The type is referred to by code in other compilation units of the package in which the type is declared.
* The type is declared public (and therefore is potentially accessible from code in other packages).
This restriction implies that there must be at most one such type per compilation unit. This restriction makes it easy for a compiler for the Java programming language or an implementation of the Java virtual machine to find a named class within a package; for example, the source code for a public type wet.sprocket.Toad would be found in a file Toad.java in the directory wet/sprocket, and the corresponding object code would be found in the file Toad.class in the same directory.
When packages are stored in a database (�7.2.2), the host system must not impose such restrictions.
(emphasis mine)

Public class name same as file name

Similar Messages

Maybe you are looking for