Develop Reference

Why does the whole package structure need to be included in Class.forName()?

I have developed a normal Java project and I am trying to understand the difference between ClassNotFoundException and NoClassDefFoundException. I have found one weird behavior, which is that I need to include the whole package structure when I am calling Class.forName().
See the code below:
package org.com;
public class MainApp {
public static void main(String[] args) {
try {
Class cls = Class.forName("org.com.MainApp");
System.out.println("Class = " + cls.getName());
} catch(ClassNotFoundException ex) {
System.out.println(ex.toString());
}
}
}
If I use Class.forName("MainApp") instead of Class.forName("org.com.MainApp") an exception is thrown.
Can someone please explain the actual reason for this?

Basically, because the contract says so:
className - the fully qualified name of the desired class.
You could very well have two classes named MainApp, in different packages. How would the classloader know which class to load if you omit the fully qualified name (i.e. including the package)?
In other words, it is a design desicion, and in my opinion, a good one.
Class.forName("MainApp") would actually try to load a class named MainApp located in the default package, that is no package name is specified in the class.

Because your class exist in that Package and forName method requires Fully Qualified name
Suppose if java has a AI to identify your classes by specifying only name, what will happend when you specify "Date" ?
Class cls = Class.forName("Date");
Is it need to give you java.util. Date class or java.sql.Date class or any third party library Date class ?
Thats why you need to specify package name to uniquely identify that class

Class.forName has no concept whatsover of your class or where it's called from.
It's a general purpose tool.
For example:
You are the ONLY person in the city called alexander.
You order a package by amazon and say, deliver it to Alexander.
You, from your perspective are the only one alexander in the city, quite easy not?
Now look from the perspective of amazon.. they have no clue where to send it.
The same logic applies to class.forName.

When you compile code, the compiler knows which package you are compiling and which classes you have imported, so when you give it a class name it can check these things to find which fully qualified class name you meant.
However, Class.forName is method on the class Class. All it knows is what you passed it, the class name. It doesn't know the package of the caller, nor what imports you used. Only the fully qualified class name can work.

Simple answer:
Same class may be part of multiple packages and JVM is not sure which class you are want to load.
You may have MainApp class in package1 and package2.
To avoid ambiguity, fully qualified class name is required in Class.forName
e.g.
Class.forName("package1.MainApp")
Class.forName("package2.MainApp")
Notes from documentation page:
public static Class<?> forName(String className)
throws ClassNotFoundException
Returns the Class object associated with the class or interface with the given string name. Invoking this method is equivalent to:
Class.forName(className, true, currentLoader)
Parameters:
className - the fully qualified name of the desired class.
Returns: the Class object for the class with the specified name.

compiling java package classes. Cannot access Class. class file contains wrong class while working with packages

I was trying to compile a few files in a package in java. The package name is library. Please have a look at the following details.
This is my Directory Structure:
javalearning
---library
------ParentClass.java
------ChildClass.java
I tried to compile in the following way:
current directory: javalearning
javac library/ParentClass.java //this compilation works fine
javac library/ChildClass.java //error over here
The following is the ParentClass.java:
package library;
class Parentclass{
...
}
The following is the ChildClass.java:
package library;
class ChildClass extends ParentClass{
...
}
The error is as follows:
cannot access ParentClass
bad class file: .\library\ParentClass.class
Please remove or make sure it appears in the correct sub directory of the classpath

You've got a casing issue:
class Parentclass
That's not the same as the filename ParentClass.class, nor is it the same as the class you're trying to use in ChildClass: class ChildClass extends ParentClass.
Java classnames are case-sensitive, but Windows filenames aren't. If the class had been public, the compiler would have validated that the names matched - but for non-public classes, there's no requirement for that.
The fact that you've ended up with ParentClass.class suggests that at some point it was declared as ParentClass, but then you changed the declared name and when recompiling, Windows just overwrote the content of the current file rather than effectively creating Parentclass.class.
Make sure your declared class name exactly matches the filename. You may well want to delete all your class files before recompiling, just to get out of a confusing state.

Java Class Saved with another name? [duplicate]

This question already has answers here:
Error: class X is public should be declared in a file named X.java
(19 answers)
Closed 9 years ago.
class Blog{
public static void main(String args[]){
System.out.println("overflow");
}
}
I am saving this file with name First.java and compiling it than it is generating file with Blog.class and gives output:
overflow
If same program i am writing as given below:-
public class Blog{
public static void main(String args[]){
System.out.println("overflow");
}
}
it gives error after compiling
First.java:3: error: class Blog is public, should be declared in a file named Blog.java

If you declare a class as public then the file name and the class name should same.Otherwise you will get compile time error.
So change you file name to Blog.java from First.java.

The reported error is really clear:
class Blog is public, should be declared in a file named Blog.java

java classes always should have same name with its file name (case sensitive) with .java extension. so you should save it Blog.java

Because it is part of the Java Language Specification! You may also have a look at Managing Source and Class Files in the Java Tutorials.

From the JLS
If and only if packages are stored in a file system (§7.2), 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 Java compiler
to find a named class within a package. In practice, many programmers
choose to put each class or interface type in its own compilation
unit, whether or not it is public or is referred to by code in other
compilation units.

How to ignore java filename?

It gives an error "Could not find the main class: filename.java" How do I set the filename to be independent of the class names?

You can't ... In Java the file name has to match the name of the public class in the file
See Why are filenames in Java the same as the class name? for an explanation

Short Answer: You can't. One class per file is the java way. Accept that or find another language.
Longer Answer: You can but you probably don't want to.
If you have one public class and x number of non-public classes, you can put the all in the same file by nesting the non-public classes inside the public class. For example (in BlowFish.java):
public class BlowFish
{
class Hooty
{
}
class Sushi
{
}
}

you can't. a java class must be in a .java file with the same name.

maybe is into the manifesto file where you are defining this class as your main class

Sure you can. Just put version numbers in your classnames, as well.
Or keep the newest as the classname.java, with older versions getting version numbers.
Or drop the version numbers and use source code control.

Java: Multiple class declarations in one file

In Java, you can define multiple top level classes in a single file, providing that at most one of these is public (see JLS §7.6). See below for example.
Is there a tidy name for this technique (analogous to inner, nested, anonymous)?
The JLS says the system may enforce the restriction that these secondary classes can't be referred to by code in other compilation units of the package, e.g., they can't be treated as package-private. Is that really something that changes between Java implementations?
e.g., PublicClass.java:
package com.example.multiple;
public class PublicClass {
PrivateImpl impl = new PrivateImpl();
}
class PrivateImpl {
int implementationData;
}

Javac doesn't actively prohibit this, but it does have a limitation that pretty much means that you'd never want to refer to a top-level class from another file unless it has the same name as the file it's in.
Suppose you have two files, Foo.java and Bar.java.
Foo.java contains:
public class Foo
Bar.java contains:
public class Bar
class Baz
Let's also say that all of the classes are in the same package (and the files are in the same directory).
What happens if Foo refers to Baz but not Bar and we try to compile Foo.java? The compilation fails with an error like this:
Foo.java:2: cannot find symbol
symbol : class Baz
location: class Foo
private Baz baz;
^
1 error
This makes sense if you think about it. If Foo refers to Baz, but there is no Baz.java (or Baz.class), how can javac know what source file to look in?
If you instead tell javac to compile Foo.java and Bar.java at the same time, or if you had previously compiled Bar.java (leaving the Baz.class where javac can find it), or even if Foo happens to refer to Bar in addition to Baz, then this error goes away. This makes your build process feel very unreliable and flaky, however.
Because the actual limitation, which is more like "don't refer to a top-level class from another file unless it either has the same name as the file it's in or you're also referring to another class that's named the same thing as that file that's also in that file" is kind of hard to follow, people usually go with the much more straightforward (though stricter) convention of just putting one top-level class in each file. This is also better if you ever change your mind about whether a class should be public or not.
Newer versions of javac can also produce a warning in this situation with -Xlint:all:
auxiliary class Baz in ./Bar.java should not be accessed from outside its own source file
Sometimes there really is a good reason why everybody does something in a particular way.

My suggested name for this technique (including multiple top-level classes in a single source file) would be "mess". Seriously, I don't think it's a good idea - I'd use a nested type in this situation instead. Then it's still easy to predict which source file it's in. I don't believe there's an official term for this approach though.
As for whether this actually changes between implementations - I highly doubt it, but if you avoid doing it in the first place, you'll never need to care :)

I believe you simply call PrivateImpl what it is: a non-public top-level class. You can also declare non-public top-level interfaces as well.
e.g., elsewhere on SO: Non-public top-level class vs static nested class
As for changes in behavior between versions, there was this discussion about something that "worked perfectly" in 1.2.2. but stopped working in 1.4 in sun's forum: Java Compiler - unable to declare a non public top level classes in a file.

You can have as many classes as you wish like this
public class Fun {
Fun() {
System.out.println("Fun constructor");
}
void fun() {
System.out.println("Fun mathod");
}
public static void main(String[] args) {
Fun fu = new Fun();
fu.fun();
Fen fe = new Fen();
fe.fen();
Fin fi = new Fin();
fi.fin();
Fon fo = new Fon();
fo.fon();
Fan fa = new Fan();
fa.fan();
fa.run();
}
}
class Fen {
Fen() {
System.out.println("fen construuctor");
}
void fen() {
System.out.println("Fen method");
}
}
class Fin {
void fin() {
System.out.println("Fin method");
}
}
class Fon {
void fon() {
System.out.println("Fon method");
}
}
class Fan {
void fan() {
System.out.println("Fan method");
}
public void run() {
System.out.println("run");
}
}

Just FYI, if you are using Java 11+, there is an exception to this rule: if you run your java file directly (without compilation). In this mode, there is no restriction on a single public class per file. However, the class with the main method must be the first one in the file.

1.Is there a tidy name for this technique (analogous to inner, nested, anonymous)?
Multi-class single-file demo.
2.The JLS says the system may enforce the restriction that these secondary classes can't be referred to by code in other compilation units of the package, e.g., they can't be treated as package-private. Is that really something that changes between Java implementations?
I'm not aware of any which don't have that restriction - all the file based compilers won't allow you to refer to source code classes in files which are not named the same as the class name. ( if you compile a multi-class file, and put the classes on the class path, then any compiler will find them )

Yes you can, with public static members on an outer public class, like so:
public class Foo {
public static class FooChild extends Z {
String foo;
}
public static class ZeeChild extends Z {
}
}
and another file that references the above:
public class Bar {
public static void main(String[] args){
Foo.FooChild f = new Foo.FooChild();
System.out.println(f);
}
}
put them in the same folder. Compile with:
javac folder/*.java
and run with:
java -cp folder Bar

According to Effective Java 2nd edition (Item 13):
"If a package-private top-level class (or interface) is used by only
one class, consider making the top-level class a private nested class
of the sole class that uses it (Item 22). This reduces its
accessibility from all the classes in its package to the one class
that uses it. But it is far more important to reduce the accessibility
of a gratuitously public class than a package-private top-level class:
... "
The nested class may be static or non-static based on whether the member class needs access to the enclosing instance (Item 22).

No. You can't. But it is very possible in Scala:
class Foo {val bar = "a"}
class Bar {val foo = "b"}