«

On Sep 4, 6:44*pm, Tom Anderson <t...@urchin.earth.li> wrote:
....
> What i would support would be an int return type from main, so you can
> return an exit code to the OS. I don't see why one should have to use
> System.exit to do that.

One reason is because System.exit() may occur long
after the main() has ended, in a multi-threaded
(e.g. GUId) application.

--
Andrew Thompson
http://pscode.org/

On Sep 5, 11:54*am, Arne Vajhøj <a...@vajhoej.dk> wrote:

(runtime arguments)
> >> I've used them, mainly when running from commandline.
>
> > Same here. I've used them a lot.
>
> So have I, but of the different types of Java apps:
> * *- SE console apps
> * *- SE GUI apps

A GUId app. launched using webstart that suggests
file associations..

> * *- SE applets
> * *- EE apps
> * *- ME whatever such apps are called
> only the first category is potential command line arguments.

...should logically expect arguments handed to
the main() (though obviously not 'command line'
args. - I am not sure how you meant that).

Here is a JNLP file service API demo. that claims
file associations..
<http://pscode.org/jws/api.html#fs>

--
Andrew Thompson
http://pscode.org/

On Thu, 4 Sep 2008, Tegiri Nenashi wrote:

> On Sep 3, 9:38*pm, Lionel van den Berg <lion...@gmail.com> wrote:
>> On Sep 4, 2:31*pm, Tegiri Nenashi <TegiriNena...@gmail.com> wrote:
>>
>>> Now that I don't use these arguments, I never feel to make a
>>> concentrated effort to remember them. Why bother remembering something
>>> that I can easily copy over from somewhere else. However, after doingg
>>> this same trick for 100 time, I ask why Java can't just be simplified
>>> to allow
>>
>>> * static void main() {
>>> * }
>>
>>> as a program entry point?
>>
>> Considering you ownly write one main method for an application it is
>> hardly a common inconvenience, I therefore see no real reason to
>> support your suggestion.
>
> I suggest the main method is used a lot more often than one per
> application. I test every sophisticated method by invoking from the
> main, e.g.
>
> Class Topology {
> ...
> public static void main( String[] args ) {
> Cylinder c = new Cylinder("a",10,10,10,10);
> Topology t = new Topology(c);
> System.out.println(t.getOpenings());
> }
> }
>
> Therefore, almost every class has it. With this usage scenario it is
> unjustifiably verbose.

http://junit.sourceforge.net/

tom

--
All London roads are part of MY London Cycle Network. I'd like to see
some of them removed from the London Motor Network! -- Ben Jefferys

On Thu, 4 Sep 2008, Mike Schilling wrote:

> Lew wrote:
>> Tegiri Nenashi wrote:
>>>> static void main() {
>>>> }
>>
>> Mark Space wrote:
>>> Forgot the "public."
>>
>> Unless you call it from another Java class in a different package,
>> 'main()' doesn't need to be public.
>
> It's not callable from the command line unless it's public.
>
> class Hello
> {
> static void main(String[] args)
> {
> System.out.println("Hello.world.");
> }
> }
>
>
> % java -cp . Hello
> Main method not public.

I could have sworn that private main methods worked. Was that changed at
some point, or was i wrong all along?

tom

--
All London roads are part of MY London Cycle Network. I'd like to see
some of them removed from the London Motor Network! -- Ben Jefferys

On Thu, 4 Sep 2008, Arne Vajhøj wrote:

> Tom Anderson wrote:
>> What i would support would be an int return type from main, so you can
>> return an exit code to the OS. I don't see why one should have to use
>> System.exit to do that.
>
> I think it would have been fine if they had done it that way. But they
> did not and I don't think it is important enough to justify a change.

Oh, agreed, entirely. It's a very, very minor niggle.

Although the change could easily be backwards-compatible - permit main to
be void or int. I can't immediately see how it could break any existing
code.

But yes, this is really an incredibly minor point.

tom

--
All London roads are part of MY London Cycle Network. I'd like to see
some of them removed from the London Motor Network! -- Ben Jefferys

Tom Anderson <> wrote:
> On Thu, 4 Sep 2008, Mike Schilling wrote:
>> % java -cp . Hello
>> Main method not public.
> I could have sworn that private main methods worked. Was that changed at
> some point, or was i wrong all along?

Maybe you mixed it up with the classes' access:

class Test // package-visible in "."
{
private static class Rest {
public static void main(String... args) { }
}
public static void main(String... args) { }
}

java -cp . Test # ok
java -cp . Test\$Rest # ok, too

On Wed, 3 Sep 2008 21:31:01 -0700 (PDT), Tegiri Nenashi
<> wrote, quoted or indirectly quoted someone
who said :

>I'm programming java since 96 and can't remember myself ever using
>main method with arguments. Does anybody have a different experience?

I guess you write only GUIs, not utilities. I use them all the time.
--

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

Lew <> wrote:
> Tom Anderson wrote:
>> Although the change could easily be backwards-compatible - permit main
>> to be void or int. I can't immediately see how it could break any
>> existing code.
> That would be a major change to the Java language, because it does not allow
> different return types for methods in the same class with otherwise identical
> signatures. The current main() signature suffices anyway.

It's not really all that major: You still cannot have two methods
with same parameter types and different return-value *at the same time in the
same class* (including "inherited" stuff). Though you can already have *any*
one such method. No one forbids you to define this one in absence of
conflicting variants:

public static int main(String[] args) {return 0;}

The question is, whether the jvm could/should make another try at
"int main(...)" after having failed for "void main(...)", or do some
reflection first to determine whether to call void main or int main
or byte main or long main or BigInteger main or ....

While I do think it quite easily *could*,
I personally do not think it *should*,
but would still likely use it if it did.

On Sep 4, 6:50*pm, Arne Vajhøj <a...@vajhoej.dk> wrote:
> Most people uses unit tests instead of main's.

Most people belive in global warming too. Can you name a single
benefit using testing "framework"? Consider http://open.ncsu.edu/se/tutorials/junit/
the code samples there are just ridiculos.

On Sep 5, 4:34*am, Tom Anderson <t...@urchin.earth.li> wrote:
> http://junit.sourceforge.net/

The way to organize unit testing is subject to debate. This section
http://en.wikipedia.org/wiki/Unit_testing#Documentation
however, caught my attention. Now, suppose a developer came across
unfamiliar class/method with sophisticated functionality and want to
run the test in order to see how it works. Would it be easier to start
looking for unit tests that cover it, or just fire up the main method
that is sitting right there in the class itself?