What's java equivalent of C's argv[ 0 ]?

[Oliver Wong]

message

Provided you're still in the same thread main is executing in, anyways.

Damn, you got me there.

Maybe have some sort of synchronized Singleton which takes a Throwable
as part of its instantiation? All entry points to the program would "try" to
initialize the Singleton by generating a Throwable (and thus a stack trace)
and pass it on to the Singleton, who would ignore all such initializations
except for the first one, thus guaranteeing that it has the trace that
corresponds to the original entry point?

Of course, by using a Singleton, this assumes no funny business with the
class loader...

- Oliver

 

[joseph_daniel_zukiger]

Roedy Green wrote On 04/26/06 13:57,:

And the list goes on. My point is that the attempt to
identify "the program" by picking out the name of one of its
many classes is likely to fail.

Well, I did try to point out at the beginning of the thread that I am
aware of the reasons it makes much less sense in the Java world. But it
does make sense in the program I am working on, if only for now.

I'm not sure if it will make sense by the time I have it complete
enough to call it a product. I just want a simple way to see in the
Machintosh menu bar which command line I invoked to get the thing
running this time. And I don't want to go to the trouble of building a
Macintosh bundle, which is the preferred place to specify the -D
property which becomes the Application menu name.

(The Application menu is, at present, more-or-less unique to the Mac OS
X GUI run-time, so the code in question is conditional to running under
Mac OS X. Well, the name is collected on all platforms, but only used
on the Mac under OS X, the way I have it now.)

There really isn't such a
thing as "the program" in Java; there's just a collection of
classes the JVM happens to load, and that collection can vary
from one run to the next. There's no "there" there, not in
the same way there is for a statically-linked language.

I'm not sure I agree with the argument, as it asserts as the primary C
programming context a family of technologies which I don't recognize as
valid. But I still see a utility in allowing any Class with a main()
method to publish a uniquely identifying name.

There might be a way to learn the name of the class the
JVM was told to load when it first started up, but even that
could turn out to be uninformative. If you learned that "the
program" was com.tools.java.debuggers.CoverageAnalyzer, the
information might not be of a lot of use ...

So you don't use it if it's not useful. That's fine with me, especially
since I now know there is a way to do it without creating implicit
semantic bindings. I don't particularly care that it takes a little
extra code, as long as I know that the code, once in place, won't get
out of sync even if I rename the class using a plain old text editor.
That was my primary concern for starting this thread, and I do
appreciate all the comments.

 

[joseph_daniel_zukiger]

Then I needn't bother sending the reply I had planned to tell you
exactly that...

Of course, I also won't tell you that I'd never use an application named
"lousy"...(I know, I'll never make it in comedy).

My wife was worried that I was going to name one of the kids "Lousy".
8-(

I should note somewhere in this thread, that in the particular case I'm
working on, static initializations actually get there in time to get
the Application menu named.

I'm vaguely aware that I'll want to back the code out when I'm ready to
build a Macintosh bundle, but it helps for now.