argv[0] in Java (again)

Interesting Question. Would like to participate

If you find a better way to do this let me know. I'm looking for this since 1996. ;-)

if you know the class, then why not using this to create your instance?
    MyClass.newInstance()

Okay:

public class ApplicationFramework
{
    public void doTheRealWork() {}
    static public void main(String[] args) {
        // want to instantiate some subclass of ApplicationFramework
        // the name of which was supplied on the commandline as the executable
        // java class name; I don't know the class here
        ApplicationFramework app = new /*NameUnknown*/;
        app.doTheRealWork();
    }
}

public class MyApp
    extends ApplicationFramework
{
    public void doTheRealWork() {
        // something wonderful happens here (with very few lines of code)
    }
}

Want to run the program with the line:

% java MyApp

BUT main is defined in ApplicationFramework, not MyApp, so main does not know the class MyApp (though the JVM knew it to load it).

Hope this makes the problem clearer

You can't! Believe me, this is not worth to waste your time.
You may write your own native Java loader that passes the class name to the main method but there is no way to do this directly in Java.

I have a abstract class CmdLineTool that would need this as well. Here what I use to work around this:

public abstract class CmdLineTool
{
    protected static void runMain( CmdLineTool clt, String[] args )
    {
        try {
            clt.initCmdLineOptions();
            clt.processArgs( args );
            clt.execute();
        } catch( Throwable ex ) {
            clt.error( ex, null );
            System.exit( 1 );
        }
        System.exit( 0 );
    }
}

public class Converter extends CmdLineTool
{
    public static void main( String[] args )
    {
        runMain( new Converter(), args );
    }
}

> % java MyApp

What specific advantages does that give you over using:

% java ApplicationFramework MyApp

Hi bcladd,

You just have to declare the doTheRealWork method as abstract:

public abstract class ApplicationFramework
{
    public abstract void doTheRealWork();
    static public void main(String[] args) {
        // want to instantiate some subclass of ApplicationFramework
        // the name of which was supplied on the commandline as the executable
        // java class name; I don't know the class here
        ApplicationFramework app = new /*NameUnknown*/;
        app.doTheRealWork(); // <-- will call MyApp without knowing the class name
    }
}

forget my last comment.

ok, i understand the problem now (the code you posted helped)...
but i still don't understand why you want to do that.
your "java" command argument is supposed to be the class that holds the main method, and not a child class.
as objects suggested, you can use this java command instead:
% java ApplicationFramework MyApp

...or just have classes that extend your ApplicationFramework provide their own main method ???

Assume the framework is educational. I would like programs using the framework to run just like future programs NOT using the framework are run. I also want the framework-based programs to require as little code as possible; students should not need to write main for the first several labs.

GrandSchtroumpf - The java command argument is suppsed to be a class that HAS a main method (it MUST have one) so there is nothing wrong with using a class that extends a class with a main function.

I have a solution (I think) and will post more in a moment if posting works again.

-bcl

the method I suggested above meets all those criteria that I can tell, and requires no change to the framework-based programs.

Sorry about the delay; I have been having problems filling out forms lately (don't know if the problem is on the wire or on the browser).

objects - Your proposal requires a change in command-line when NOT using the framework. This framework is educational and is supposed to support the student at the beginning but be light-weight enough that it can go away as the student learns enough Java. By providing my main() the student can focus on other methods and write an interactive program with little programming (and then the structure of a program can be exposed a little bit at a time over several programs).

-bcl

> but be light-weight enough that it can go away as the student learns enough Java.
if the sudents' classes extend the framework it will be hard for it to go away.
anyway, the first thing you learn in java is to write a main method (with a sys.out that displays hello world).

> Your proposal requires a change in command-line when NOT using the framework.

Running *any* different app would require a change in the command line.
One could argue that the approach you are attempting would result in your students believing that they can run any Java class without having a main.

(1)  One of the problems with Java as a first language is the amount of baggage that is required for something as simple as HelloWorld.java. The students must, at a minimum
  - Write the defintion of a class
  - Define a static method called main taking an array of String objects as a parameter
    - Students are not stupid; they don't like being forced to use magic incantations
    - Students are too inexperienced to use public static void main(String[] args) as anything BUT an incantation.
  - Ignore the arguments completely
  - Invoke a method on an object that is a member of an object passing a literal string as a parameter.
And when it is done they get a console application (I have had more than a few students in the past couple of years who didn't recognize what a console window is at first) that is not interactive at all.

Kim Bruce's work at Williams College using an events-first approach (an approach I toyed with back in graduate school but let slide) inspired me to provide a different introduciton to the language. Granted, class syntax is still necessary but if the methods overridden by the students are simple (void with no parameters for some, void with a single parameter for others), then the students' introduction to methods is gentler.

(2) The command-line changes to include the name of the class being executed, true, but the FORM of the command-line is not changed. That is, the number of parameters to the java virtual machine does not change and the meaning of each parameter doesn't change. There is some risk that students will think they can execute any class file in isolation (though not the same risk as using an IDE like BlueJ where in the IDE that is true). Two things will work against that: when they stop extending the framework they will be writing their own main method (later in their learning the idea of static will not be as scary and it will be a chance to introduce arrays and command-line parameters); if they "run" classes other than those that extend the framework the JVM will crash (and, one hopes, they will ask questions or read ahead).

-bcl

By the way, using the ClassScope class over at JavaWorld () I found a solution to my particular problem:

  public static void main(String[] args) {
    Class[] allClasses
      = ClassScope.getLoadedClasses(ClassLoader.getSystemClassLoader());
    int i;
    Class applicationClass = null;
    Class frameworkClass = null;
    ApplicationFramework af = null;
   
    try {
      frameworkClass = Class.forName("ApplicationFramework");
    } catch (ClassNotFoundException e) {
    }

    try {
      for (i = 0; i < allClasses.length; ++i) {
        Object o = allClasses[i].newInstance();
        if ((o instanceof ApplicationFramework)
            && (allClasses[i] != simpleGameClass)) {
          applicationClass = allClasses[i];
          sg = (ApplicationFramework)o;
          break;
        }
      }
    } catch (InstantiationException iex) {
    } catch (IllegalAccessException iex) {
    }

    if (applicationClass != null) {
      af.doTheRealWork();        
    } else {
      System.err.println("No application found to match.");
    }
  }

-bcl

Forgot to insert the JavaWorld link in the above: http://www.javaworld.com/javaworld/javaqa/2003-07/02-qa-0725-classsrc2.html

-bcl

PAQ and refund is ok for me.

bcladd, your solution looks promising although it's unfortunatly not an option in a real framework that has to work with more than one VM implementation.

If you want to hide as much as possible of the Java command line I think a single line batch file could fit even better because it can also hide other VM options that might be neccessary to run your framework.
runclass.bat:
  c:\j2se\bin\java.exe -mx... -cp ...;%~dp1 pkg.ApplicationFramework %~n1

(%~dp1 is used to append the path of the class to the classpath and %~n1 gives just the class name)

And it would allow your students to double click their class files if you register it for the .class extension:
C:\> ftype runclass=%SystemRoot%\runclass.bat "%1"
C:\> assoc .class=runclass

Although this would only work for classes that do not have a package.

If you are looking to ease use for your students then the following may be useful to you:

http://www.objects.com.au/products/jstart.do