«

Hi All ,

I have the following query :-

If I define the main method as a Private , then run the demo program
the program obviously doesnt run ,we have a runtime error .What
exactly is the reason behind it .

I know its not a good programming practice and the main should always
be in Public.
But I want a conceptual answer as to why its not a valid thing to make
the main as Private.
Any help would be highly appreciated .

Regards,
Abhishek.

schrieb:
> Hi All ,
>
> I have the following query :-
>
> If I define the main method as a Private , then run the demo program
> the program obviously doesnt run ,we have a runtime error .What
> exactly is the reason behind it .

The JVM looks for a public static main method that takes a String array
as parameter.

>
> I know its not a good programming practice and the main should always
> be in Public.
> But I want a conceptual answer as to why its not a valid thing to make
> the main as Private.
> Any help would be highly appreciated .

It's specified to work this way, e. g. have a look at [1].

Not focusing the specification: public methods may be called from other
classes in other packages, e. g.

OtherApp.main(new String[]{});

Of course, one can use reflection to generalize this.

Bye
Michael

[1]
<http://java.sun.com/docs/books/jls/third_edition/html/execution.html#12.1.4>

wrote:

> Hi All ,
>
> I have the following query :-
>
> If I define the main method as a Private ,

private, it doesn't have a capital letter.

> then run the demo program
> the program obviously doesnt run ,we have a runtime error .What
> exactly is the reason behind it .

Because a private method is only visible in the class in which it is defined. So
a private main() method is not visible to the JVM so it cannot invoke it.

>
> I know its not a good programming practice and the main should always
> be in Public.

It's not that it's bad programming practice, it just won't work.

> But I want a conceptual answer as to why its not a valid thing to make
> the main as Private.
> Any help would be highly appreciated .
>
> Regards,
> Abhishek.

--
Nigel Wade, System Administrator, Space Plasma Physics Group,
University of Leicester, Leicester, LE1 7RH, UK
E-mail :
Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555

On Feb 8, 9:37 am, abhishek.r...@gmail.com wrote:
> Hi All ,
>
> I have the following query :-
>
> If I define the main method as a Private , then run the demo program
> the program obviously doesnt run ,we have a runtime error .What
> exactly is the reason behind it .
>
> I know its not a good programming practice and the main should always
> be in Public.
> But I want a conceptual answer as to why its not a valid thing to make
> the main as Private.
> Any help would be highly appreciated .
>
> Regards,
> Abhishek.

The idea behind the private modifier is that, in general, the member
is only visible within your class: you want to keep it totally under
your control because it's some sort of internal method or property
that the outside world has no business fiddling with.

The point of a public method is that you're exposing an interface
(with a small 'i') to the outside world that anyone can come along and
interact with. You don't get much more "outside world" than the
command line.

Technically, any modifier could have been specified but "public" fits
more with its use.

(Aside.) Whether the convention of having a method with a magic
signature as the entry point into all standalone java programs is
better than some more explicit approach like an Interface might be
worth wondering about. It made the original sales case for java closer
to C I suppose. I expect other people can come up with better
arguments either way.

Matt

"Matt Rose" <> wrote in message
news: oups.com...
>
> (Aside.) Whether the convention of having a method with a magic
> signature as the entry point into all standalone java programs is
> better than some more explicit approach like an Interface might be
> worth wondering about. It made the original sales case for java closer
> to C I suppose. I expect other people can come up with better
> arguments either way.

From my perspective, it's not that method which has a magic signature:
the evidence is that you can have multiple class each with their own "public
void static main(String[])" methods, and none of them are any more magical
than any other. Rather, it's the behaviour of the JVM itself which is
"magical". It can somehow manage the transfer of control from the command
line (or other external environment) into the JVM.

It just so happens that the "java.exe" command happens to take a class
as a command line argument, and tries to invoke the static main(String[])
method of that class. But this is not conceptually different from a browser
creating an instance of a JApplet, and invoking its init(), start() and
stop() and destroy() methods. Doesn't mean that the JApplet is magical. It
just means that there's some sort of transfer of control from your program
to the outside environment.

I believe there are even IDEs for which you can specify the entry point
to be something other than a method called "main" (e.g. a static method
called "foo(String[])" instead), which further reinforces that the magic
lies not in the method, but somewhere at a higher level than that.

- Oliver

"Oliver Wong" <> wrote in message
news:63Kyh.13841$...
> "Matt Rose" <> wrote in message
> news: oups.com...
>>
>> (Aside.) Whether the convention of having a method with a magic
>> signature as the entry point into all standalone java programs is
>> better than some more explicit approach like an Interface might be
>> worth wondering about. It made the original sales case for java closer
>> to C I suppose. I expect other people can come up with better
>> arguments either way.
>
> From my perspective, it's not that method which has a magic signature:
> the evidence is that you can have multiple class each with their own
> "public void static main(String[])" methods, and none of them are any more
> magical than any other. Rather, it's the behaviour of the JVM itself which
> is "magical". It can somehow manage the transfer of control from the
> command line (or other external environment) into the JVM.
>
> It just so happens that the "java.exe" command happens to take a class
> as a command line argument, and tries to invoke the static main(String[])
> method of that class. But this is not conceptually different from a
> browser creating an instance of a JApplet, and invoking its init(),
> start() and stop() and destroy() methods. Doesn't mean that the JApplet is
> magical. It just means that there's some sort of transfer of control from
> your program to the outside environment.
>
> I believe there are even IDEs for which you can specify the entry point
> to be something other than a method called "main" (e.g. a static method
> called "foo(String[])" instead), which further reinforces that the magic
> lies not in the method, but somewhere at a higher level than that.

There is nothing "magical" about it at all. It is called a "standard
interface" -- a publicly documented protocol that everyone agrees on (or
must accept even if they don't agree).

public static void main(String[] args) {...}

is the standard entry point for all Java applications.

Karl Uppiano wrote:

> There is nothing "magical" about it at all. It is called a "standard
> interface" -- a publicly documented protocol that everyone agrees on (or
> must accept even if they don't agree).
>
> public static void main(String[] args) {...}
>
> is the standard entry point for all Java applications.

Not really true. It's the way that the specific launcher /for/ Java
applications called (on Windows) java.exe, or javaw.exe is written. But there
is nothing blessed about that launcher -- anyone can write their own which uses
any entry-point they like, or no enty-point at all.

-- chris