What is the Prototype for Main method in java

Hi all
I have a small doubt please clarify me
What is the prototype for main method it is seeing silly question but i am confusing with this.
public static void main(String args[])
in the above prototype java language specification giving that all are required but i am getting the class executed with out public also then what is the prototype for main method. If it is required public then why it is executing with out public if not in jls why they are given that public is required for main method
can any one clarify me...

Narayana Murthy,
Welcome to JavaRanch!
Have you seen our new Certification FAQ??. You will find the answer there!!
This question has been asked here before a lot of times. I urge you to use the search engine to browse the old topics before posting a question in the future. It will save you time waiting for someone to answer

Ajith

Hello Ajith Kallambella
I have seen ur answer for this but i am not satisfied with that u are saying that the main method will work with private modifier also. Sun people are not considering this as a bug, then why in jls they given that public is must for main method can u elaborate this for me please .
[This message has been edited by Narayana Murthy (edited November 14, 2000).]

Hi!
This is my first time. So, forgive me if I am wrong. I think the only requirment for main method is that it should reside in a public class, and other is that it should be a static method. There is no other requirments.

Narayana Murthy,
I woudnt take java's access modifiers seriously if I were you.
This is an extract from a bug report I logged with sun.
The private access modifier can be bypassed because the check is done only at
compile time.
<pre>
public class TestA {
private void foo()
{
System.out.println("Hello you have just called a private method");
}
}

public class Test {
private static void main(String[] args)
{
TestA t = new TestA();
t.foo();
}
}
</pre>
First compile class TestA with foo() as a public method. Then compile class
Test. Go back and change foo() to private. Re-compile. class Test executes
the private method foo() of class TestA.
Cheers
Sahir
[This message has been edited by Sahir Shah (edited November 15, 2000).]

hello Sahir
U can not call private methods out side the class .
That will not call foo method at any cost see once again.
I am not getting why u got that so please see once agian and clarify me .
in sun jls they clearly mention that main method must be a public then how come this ?
that is what my doubt are u getting me .

<pre>
Narayana Murthy,
Class TestA should be in file TestA.java .
Make the method foo() public and compile it.
Create class Test in file Test.java.
Compile Test.java.
Execute class Test.
So far so good.
Now reopen TestA.java change the method foo() to private.
Re-compile TestA.
Go back to class Test.
Dont compile just run it and see what happens.
Cheers
Sahir
</pre>

Hai Sahir
I have seen that it is amazing to see that result i am really surprised about that .
Can u elaborate what is happening besides screen please.
Is there any old ref to that class if so also i changed the content of the class then also it is giving what is happening here please elaborate this .
Thanks in advanse.

This is the certification forum. The only correct answer for the exam is:
public static void main (String[] args)
or valid reordering of the above
static public void main (String args[])
Just because, in practise, you can make main private, does not make it the correct answer for the exam. Ajith made this clear in the FAQ.
[This message has been edited by Graeme Brown (edited November 16, 2000).]

Hai Graeme Brown
I know that this is a certification forum and as per my knowledge i don't think that to clear the doubt where we are ? Is it right or not . Who says that for certification there is a rule that they will give public static void main(String arg[]) only why not private static void main(String args[]) if at all it is there please notify me...
I am confused with jls there i seen that for main method it is must be public and in the practise it is working with out public also why this ? please clarify me...

[This message has been edited by Narayana Murthy (edited November 16, 2000).]

I think you have answered your own question, the JLS says main must be public, therefore that is the correct answer for the exam.
Unless anyone else knows different?

Hai Graeme Brown
Thanks for giving a quick reply.
But i am not expected this response from u . I told in the previous thread that forgot about scjp exam and i need some clarification about this . Can u please give the clarification for this ?
I am expecting a good response on this from u ..
Thanks once agian..

[This message has been edited by Narayana Murthy (edited November 16, 2000).]

Hi...
What I think is that since Sun JVM does allow a private main method to work OK, it just means that
1. there is a bug in the JVM,
2. JVM is not 100% JLS compliant.
If you have access to a solaris/ linux machine you can try it out there to see if the problem is only in Windows JVM or it exists there also.
Alternatively, A JVM from IBM, called Jikes is supposed to be 100% JLS compliant. Can someone who has this try it out on JIKES and see what the result is?
TIA,
Shubhangi.

In java 1.1 and before java 1.2 if the main method was not public static then compiler gave erreor message.
in java 1.2 and above u can give any access modifer to main method coz it is entry point method for your code. This is possible because a new class is added in java2 AccessibleObjects which only jvm can use. this class allow to bypass the access modifier for main method only if it is STATIC & VOID main(String argas[]) Note any other defination will not be considered as entry point method

Narayana Murthy,
I was up util the wee hours of the morning trying to get at the private int value member of the class Integer(). I created a shadow class called Integer() and succeeded in fooling the compiler into thinking this was java.lang.Integer()
and not just .Integer(). After compiling the two classes, I got the shadow Integer()out of the way to see if the class loader will go hunting for the real Integer() in rt.jar. It did but I got a run time illegal access exception. This has something to do with the way classes are loaded. I guess the classes in jar files are loaded in a different way from standalone classes. However I have not given up. What intrigued me most was whether this could be used to punch a hole in java's security system. I asked a few java luminaries
including Bruce Eckel. I believe there is a potential possibility because he did not pooh pooh it straightaway. He has referred this to some one called Bill. I am not sure which Bill,
this Bill could be some big java gun (maybe Bill Joy). We shall soon have an answer, right from the horses mouth. Shall keep you posted.
Rgds
Sahir

[This message has been edited by Sahir Shah (edited November 17, 2000).]

Hi Saher I will be very happy if you post the code, that way we can also try on this and see why this is happening.
Thank you

Hello Sahir Shah
I seen ur tactic to get the system classes access but i am not able to under stand it 100% what u are saying . I done some thing by seeing ur thread i don't know whether it is same as u think about it or not please see this code and give me exactly what u are thinking about this.
public class Integer
{
public static void main(String s[])throws SecurityException
{

Integer i = new Integer();
System.out.println(i.getClass()+"\n"+i.getClass().getSuperclass());
java.lang.reflect.Method m[] = i.getClass().getMethods();

for (int j=0;j<m.length;j++)>
System.out.println(m[j].getName());
}
}
This program i created with Integer name only it is compiling u said that jvm is taking this as java.lang.Integer what i understood with ur post.
But when i do introspect this class it is not taking as a java.lang.Integer class.
Please clarify me if at all i goen wrong ...

[This message has been edited by Narayana Murthy (edited November 16, 2000).]

Hello friends here is my part of story. I have made two source files with same names as P1.java in one dir, and other with P1.java in other dir. Here are the files:
// In one dir
public class P1{
public static void main(String args[]){
System.out.println("P");
}
}
//End
//In other dir
public class P1{
private static void main(String args[]){
System.out.println("P");
}
}
//end
then i have compiled them.
And here is the most surprising part when i have looked at there hex code i was totally shocked it was same for both files. I think the compiler is completely ignoring the mdifiers for main method can any body in the world exlain this. Why it is compiling same.

Narayana Murthy,
Use the same method you use for creating your own packages eg:- package com.yourname.packagename;
For details refer to Bruce Eckels TIJ or
Patrick Naughton's The Complete Java Reference ( Chapter 9. Packages and Interfaces. Section - Understanding CLASSPATH.)
Asim Wagan,
I am not ready yet to post the code because I am not able to conclusively prove that you can get at the foundation classes private members. All I have managed so far is to fool the compiler. It has to run successfully and bushwhack one of the core classes. If I manage to do that I shall certainly post it here. If any of you guys have any suggestions please post it here. Many heads are better than one.
Rgds
Sahir

[This message has been edited by Sahir Shah (edited November 17, 2000).]

Hello Sahir Shah
I am not able to under stand what u are saying in this thread can u please explain me in detail ..
Are u get that private method access why that is getting from test class if so please give a solution for that ..

Originally posted by Sahir Shah:

Narayana Murthy,
Use the same method you use for creating your own packages eg:- package com.yourname.packagename;
For details refer to Bruce Eckels TIJ or
Patrick Naughton's The Complete Java Reference ( Chapter 9. Packages and Interfaces. Section - Understanding CLASSPATH.)
Asim Wagan,
I am not ready yet to post the code because I am not able to conclusively prove that you can get at the foundation classes private members. All I have managed so far is to fool the compiler. It has to run successfully and bushwhack one of the core classes. If I manage to do that I shall certainly post it here. If any of you guys have any suggestions please post it here. Many heads are better than one.
Rgds
Sahir

[This message has been edited by Sahir Shah (edited November 17, 2000).]

I remember seeing on java site a note recognizing this bug and also saying that there are no plans to fix it for some technical reasons which are beyond the scope of my understanding presently.
Also while testing this bug/ feature, I found that if we compile with private static void main, then any subclass of the class can be used to invoke it, even if the subclass doesnt have a main method at all. So this private modifier doesnt behave like private in true sense of the word.

Narayana Murthy,
Suppose you have just one class path defined in your machine and its D:\Java and you have used a package declaration com.NarayanaMurthy.utils; in some java source file, this file should be stored in D:\Java\com\NarayanaMurthy\utils , all the class files in this folder can have the same package declaration and they become part of the package com.NarayanaMurthy.utils; This com business is a convention used to avoid clash of class names, it is obtained by inverting your internet domain name.
So what you do is save the file Integer.java as D:\Java\java\lang\Integer.java it should have the package declaration package java.lang; You can create a shadow of any native java class this way. But just leave Integer() alone , its not worth it , concentrate on the package java.security; package, that should yield more dramatic results if you manage to break it.
Rgds
Sahir

Narayana Murthy,
Sorry. I might have misunderstood your question. The above post contains instructions on fooling the compiler. About what is
actually happening here. Well I dont know the full story yet. Apparently access modifiers are only checked at compile time in certain cases. So after you compile the caller class if the called class has been modified and the access modifier is now private the run time system ignores it. It isnt working with the java native classes right now. But it is worth a try.

Rgds
Sahir

Hello Sahir
I understood what u are saying but one thing i have to remember u that u told that runtime system ignores it but i am not sure this will happen why because all necessary classes will be loaded in to the JVM at the time of class loading only class loader will invoked when we called the interpreter how come it ignores by runtime system please clarify me ..
Murthy

Originally posted by Sahir Shah:

Narayana Murthy,
Sorry. I might have misunderstood your question. The above post contains instructions on fooling the compiler. About what is
actually happening here. Well I dont know the full story yet. Apparently access modifiers are only checked at compile time in certain cases. So after you compile the caller class if the called class has been modified and the access modifier is now private the run time system ignores it. It isnt working with the java native classes right now. But it is worth a try.

Rgds
Sahir

Sahir, you may want to read Using the BootClasspath - Tweaking the Java Runtime API if you haven't read it already

--------------------
But I have been wrong before. -- Jason Menard

Originally posted by Narayana Murthy:
Hello Ajith Kallambella
I have seen ur answer for this but i am not satisfied with that u are saying that the main method will work with private modifier also. Sun people are not considering this as a bug, then why in jls they given that public is must for main method can u elaborate this for me please .
[This message has been edited by Narayana Murthy (edited November 14, 2000).]

Hi,
This has been reported as a bug.

Hope this helps,
Vanitha.

it can also be final and thow exceptions

It can be even inherited.

Hello asim
I have compiled both classes of your example and analized the class files with a parser that you can find here
and the result is fortunately different:
for public the declaration of main is translated to the following bytecodes

00 access_flags
99 0000000000001001staticpublic
00 name_index
11b main
00 descriptor_index
12c ([Ljava/lang/String V
00 attributes_count
11 1

for private:

00 access_flags
10a 0000000000001010staticprivate
00 name_index
11b main
00 descriptor_index
12c ([Ljava/lang/String V
00 attributes_count
11 1

[ April 05, 2002: Message edited by: Jose Botella ]

Hello Sahir
Bill Venners did a good attemp (in vane) to fool Java security in his book Inside The Java 2 Virtual Machine. This is his site: www.artima.com
There are several problems to do that:
When a java application starts at least three class loader, chained in a hierarquy, are created. The bootstrap class loader, responsible for loading the classes in the API. The exension class loader that loads from the extensions directory, and the classpath class loader that loads the application.
The extension class loader is the parent of the classpath one. And the boostrap is the parent of the extensions one. Because a class loader always aks for its parent to load a class before trying itself, the boostrap class loader always will load the classes in the API.
However things get more interesting if we are trying to replace a class of an application (not in the API). I don't know how to do that, the interesting part is how Java security prevents from doing it.
I am going to simplify a bit and consider a class loader the same as a name space. For the difference between them consult Bill's book.
The JVM records load constrains as it loads classes that contain references to classes loaded by other class loaders others than the one that loaded the class that contains the reference.
These load constraints say that the types mentioned in both classes must be the same type, that is, they must be the same class, and thus it is not possible to replace one with another different one.
By the way, Integer in the previous post is an example of shadowing. (JLS 6.3.1)

This is a program thats shows that loading constaints exist.
Scenario:
c:\java\test\url1 contains FieldType.java and ToLoad.java
c:\java\test\url2 contains FieldType.java and AccessingField.java
c:\java\test contains Test2.java
Note: the FieldType class in url2 is the modified version. The FieldType class in url1 is the non modified version.
ToLoad class holds a static member of type FieldTYpe. It will be loaded by the class loader cl1.

AccessingField class is going to access the field member of class ToLoad, but it will be loaded by a class loader called cl2.

When the JVM loads a class that access members declared in classes loaded by class loaders others than the one that loaded that class, it records a loading constraint. That loading constraint ensurres that the type referred to by the referencing class and the type declared in the referenced class are the same.
In our example this type is FieldType:

In the first run of Test2 the previous FieldType will be in url1 directory. Class loader cl1 loads it from cl1, cl2 gets the same class because it ask first for its parent class loader (cl1) to load tha class Fieldtype. Thus cl2 does not loads the modified version of TypeField from url2 (this time). The loading contraint is fullfilled because the same type (FieldType) is on both the referencing and the referenced class. We get no error.

Before running the second time we'll change the name of TypeField.class in url1, so that cl1 is not able to load it when receives the petition of cl2. We'll decomment out the lines that allow us a pause to rename back the file FieldType.class in url1. Before the pause cl2 has loaded the modified version of TypeField from url2. After the pause cl1 loads the non modified version. Thus they are different now and the loading constraint is enforced with an error.

It is a modified version of FieldType. Now the loading constraint produces the following error:

[ April 07, 2002: Message edited by: Jose Botella ]
[ April 07, 2002: Message edited by: Jose Botella ]
[ April 07, 2002: Message edited by: Jose Botella ]
[ April 08, 2002: Message edited by: Jose Botella ]

It seems I have problem with the length of my previous post.
This is the error:

C:\Java\test>java Test2
Loading TypeField in java.net.URLClassLoader@601bb1
Copy TypeField.class to url1 and hit Enter
Loading ToLoad in java.net.URLClassLoader@ea2dfe
Loading TypeField in java.net.URLClassLoader@ea2dfe
Loading AccessingField in java.net.URLClassLoader@601bb1
Initializing ToLoad class
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at Test2.main(Test2.java:20)
Caused by: java.lang.LinkageError: loader constraints violated when linking FieldType class
at AccessingField.printField(AccessingField.java:3)
... 5 more

Even when the sole difference is a modifier such as public and private the loading constraint check detects that the two classes are different.