+3  A: 

This is what application servers are made for. They face similar issues to provide all their services which must be brought up and teared down in a specific order to keep dependencies satisfied.

You can for example use the JBoss micro kernel which is not a lot more than some classloaders and a JMX engine. You can package your apps as 'sar' or service archives and specify the dependencies in the metadata of these packages.

You can probably do similar things with a stripped down glassfish or using Spring DM server.

Alternatively an OSGi engine like Equinox or Felix can provide similar services.

Another advantage is that you will end up with a lot less virtual machines.

Peter Tillemans
running java programs in an app server isn't always a practical option.
seand
I don't really have the option to use an app server -- a lot of these processes are from old code bases. I completely agree, that ideally I would use OSGi, if I had that option.
Grasper
OSGi is problematic for legacy stuff, however the app servers approach is a lot less complicated than many assume. It is quite straightforward to wrap an executable in an MBean and call its main method to launch it. The classloaders keep the classes out of each others hair. Maybe an option for another day?
Peter Tillemans
A: 

Unless you have an app server or some other framework as mentioned before you can do one of several things. Can you find the pid-s of these processes? If so you can try sending signals to them (for a *nix system). If you have control over the code of these java processes you can have them listen on tcp sockets; create a simple message that tell the process to shut itself down. Bascially this is an IPC situation.

seand
+4  A: 

This looks like a really bad design. There are several options to deal with the mess:

Plan A: Put everything together as one application and have it run all in the same JVM - a launcher class can run each of your now separate processes as a simple thread. If the applications don't do anything terribly evil they should be able to coexist in one JVM.

Plan B: Have each of your seperate JVMs create a ServerSocket and send them a message through the socket they should shut down.

Plan C: Get ProcessView (http://www.teamcti.com/pview/prcview.htm), it can be run from the command line and kill processes by name (with wildcards), so you could kill all java processes in one go. Its a sledgehammer solution, but may suit your short term needs.

Durandal
+3  A: 

This answer is a bit of a medium / longer term solution, but you should really look at getting, what looks like, custom .bat files out of the picture and use the Tanuki Java Service Wrapper to get all of your long lived java processes installed as Windows services with a specific name. From there, it's easy enough to create a .bat script that wraps starting and starting all of the java processes needed through the net start %SERVICE_NAME% and net stop %SERVICE_NAME commands.

The Tanuki wrapper has a community version that's free to use for the basic features, including installing as a Windows service.

whaley
+3  A: 

Read the taskkill command help: taskkill /?

TASKKILL [/S sistema [/U nomeutente [/P [password]]]]
         { [/FI filtro] [/PID idprocesso | /IM nomeimmagine] } [/T] [/F]

You can kill tasks knowing the PID or their name.

vulkanino
this is really the simplest option. just put 10 x calls to taskkill with appropriate params in a batch file. caveat: make sure each app is well enough designed to handle being shutdown prematurely and won't have an access violation and crash if you go down this route.
Anonymous Type
+2  A: 

If non-cooperative termination is OK with you then, since this is on Windows, perhaps TerminateJobObject is what you're looking for. It terminates all processes in a "job". Of course the processes have to first be associated with the job (see the MSDN Lib link).

Disclaimer: I haven't used it.

Cheers & hth.,

– Alf

Alf P. Steinbach