Internal Programmes

[Mark Heydenrych]

Hey this is a funny question

I'm writing an app to execute multiple java programmes from a single integrated application. So the programme searches for components that it can run, adds them to a combo box, the user chooses one of the components, clicks a button and the programme executes. I've also multithreaded it so that multiple components can be run simultaneously. In order to run these components, I use Runtime.getRuntime(), and proc.exec() in order to execute these components, and so far it's working perfectly. However, I want to improve the look of the programme by forcing the components to run inside the application from which you choose the components.

In other words, you run Framework.jar, and when you execute the components, when they are minimized I don't want them going to the taskbar, but rather inside my Framework window. I know things like this can be done, and I've been taking a look at internal frames and the like, however the use of Runtime.getRuntime() seems to mean that internal frames aren't really going to help.

Is there any way to do this? Or must I settle for external components?

Thanks in advance,
Mark

[Ulf Dittmer]

If those are Java executables that have a main method, what stops you from calling that main method directly from a new thread in your application?

[Mark Heydenrych]

Just to check that I understand you, when you suggest that I call the main method from within my thread, do you mean in the following way?

    
MyClass class = new MyClass();
class.main();

If so, the problem is that my system is completely dynamic. I can never know the class type of all the components that can be run from my system. For example, if a new component, say HelloWorld.jar, is added to the directory, the application will dynamically find it, add it to the list and allow it to be executed. Since I can never know the class type of every possible component that can be added, and cannot know what constructor parameters may be necessary, instantiation is completely out of the question.

If you were referring to something else, is there any chance you could elaborate a little?

Thanks in advance

[Ulf Dittmer]

OK, having to deal with arbitrary applications, the class names of which are not known at compile time, makes it a bit harder. But it's still doable.

Assuming those ARE Java applications that means that they do have a class that contains a main method with a known method signature. So as long as the integrated application knows the class name -and it has to have a way to figure those out, maybe the user enters them, or it periodically scans some directory for newly added classes and/or jar files- then the reflection API can be used to invoke their main method.

Of course, it would be better if those other apps implemented some common interface that the integrated app could use to run them.

[Rob Spoor]

For JAR files that run automatically, you can use JarFile to retrieve the Manifest and from that the main class:

JarFile file = new JarFile("HelloWorld.jar");
Manifest mf = file.getManifest();
if (mf != null)
{
    Attributes atts = mf.getMainAttributes();
    String main = atts.getValue(Attributes.Name.MAIN_CLASS));
}

[Mark Heydenrych]

Hmmm

Thanks for the help. I'll see what I can do. I have the application working, it can run any GUI app that it finds (it does scan the directory for new jars at start up - great minds think alike hey) I'll take a look at the reflection API. And I hadn't thought of having a common interface amongst them. Just to check if I have the workings of interfaces right, would I do the following?

    
public MyClass implements Executable
{
   //class code here
}

and then, in my integrated app, instantiate as follows

    
Executable e = new Executable();
e.execute();

Does something like that look more workable?

[Mark Heydenrych]

Rob:

Thanks. I was not aware that you could get a hold of the Manifest so easily from within a Java programme. Not sure ot will helo me with this problem exactly, but I AM certain that it will help me in some other way. Maybe versioning information to avoid duplicates?

Thanks

[Ulf Dittmer]

Does something like that look more workable?

Yes, that's just about what I had in mind. Besides an "execute" method you could have various other lifecycle methods, like "stop" if you are about to shut down the application, "suspend" if you get switched away from the foreground etc. Kind of like the Applet class has.

If you ever have a scenario where you don't fully trust the code you may want to use ClassLoaders and SecurityManagers to handle the code, but if those other apps consist of your code as well, then that's likely not a consideration.

[Mark Heydenrych]

Thanks so much for all the help. you guys are the greatest. You've made me a very happy bunny