Un-killable java program

Question

I have developed an application in java. I need that my java program would not terminated any process explorer/task manager.

Answer 1

Not possible...

There maybe ways to hide it from Task Manager or even other proprietary process explorers for windows but that needs access to the native win32 API.

Maybe you can use JNI(Java Native Interface) to achieve this but I am still skeptical.

& plus JVM itself is a process which can of-course be killed.

Answer 2

I believe it is not possible.

The OS should always be able to manage the application, which could involve terminating them.

Answer 3

This is not possible.

The closest you're able to achieve is to add a shut-down hook to your Java program that will block indefinitely; e.g. Runtime.getRuntime().addShutdownHook(Thread).

This will have the affect that a normal kill signal under Posix will have no effect. From Windows task manager an attempt to "End Process" will fail and Windows will eventually prompt stating that the process is unresponsive and would you like to terminate it - At this point there is no way to prevent the termination.

Answer 4

You might take a look at rmid. I think you can make it automatically restart your service whenever it went down. As far as I recall, this is what was used in Jini a lot.

(So this would give you an external watch dog, based on Java tools only. Question of course is what you are going to do when rmid itself dies. I guess do something clever with cron. But what if cron dies? And so on and so forth.)

Answer 5

As others have said, this is not possible. Raymond Chen of Microsoft has given a good explanation as to why.

Answer 6

Even if this were possible, you should not even want (let alone "need") to do this.

The only thing it could achieve is piss off users and perhaps cause legal trouble. There is no legitimate reason to do it, so don't.

Answer 7

It's possible in VC++ and other languages because you have the ability to hook directly into the OS itself. Java programs are always going through the JVM as an intermediate layer and if you were able to hook that deeply into someone's machine via JVM, as people have said, it would be an immense security hole:

Short version: If you absolutely must do that, do it in a language that compiles native binaries and has no VM between you and the OS API.