Home/ Questions/Q 8290989
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-08T12:58:42+00:00

I have some code that dynamically loads classes from several JARs in a directory.

  • 0

I have some code that dynamically loads classes from several JARs in a directory. Because the code in the JARs is untrusted, I wish to protect the main application from poorly-coded or malicious dynamic classes by “sandboxing” them. One thing I’m trying to do is “timebox” the untrusted code’s execution, and kill it if it’s taking too long (because it’s stuck in an infinite loop, for instance). I’m trying to implement this using Callable and Future, not because I want to run the tasks in parallel (I don’t), but to take advantage of work done to provide a return value, capture exceptions, and cancel running tasks. However, when I run it on some test code, I’m finding that invoking Future.cancel(true) doesn’t seem to cancel the task.

I’ve seen several questions (such as this one) on StackOverflow about why this would occur, and the answer is always the same: cancel(true) works by invoking interrupt() on the thread running the Callable, which requires that the cancelled task block on an interrupt()ible operation (such as Thread.sleep()) before the cancellation will take effect. Since I don’t control the code being executed, there’s no guarantee that it will ever do that, so I can’t be sure that I’ve cancelled it.

Is there any way that I can run dynamically-loaded code, then later kill it in progress and be sure it dies, even if it never blocks on an interrupt()ible operation?

// Assume: ExecutorService pool, Callable<T> task,
//  long timeout, TimeUnit timeUnit
Future<T> future = pool.submit(task);
T result;

try {
    result = future.get(timeout, timeUnit);
    // do something with result
} catch (TimeoutException ex) {
    future.cancel(true);
    // handle timeout
} catch (ExecutionException ex) {
    // handle exeception thrown by task
} catch (InterruptedException ex) {
    // handle InterruptedException
}
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Next to Thread.stop and Thread.destroy, you can for ultimate sandboxing, spawn a whole JVM in a subprocess with Process p = Runtime.getRuntime().exec( cmd );. The process can really be destroyed with Process.destroy if necessary.

    To ease the process creation, use ProcessBuilder. Also, look a available tutorial (this one is in french) to execute process, wait until completion (with waitFor), and manage streams.

    I’ve seen it working in a product where we needed to convert ps document to pdf. We were dumping the ps file, executing ps2pdf, then reading the output file.

    Pro/cons of Process:

    • (+) real sandboxing into a separate process
    • (-) communication between
      JVM harder to deal with
    • (-) complicates the deployment of the app
      (path of the JVM, options, current directory, etc.)

    Note that Thread.stop and Thread.destroy (I’m not sure it’s been actually implemented) are discouraged because they are unsafe with respect to locks acquisition and release. Make sure you read Why Are Thread.stop, Thread.suspend,
    Thread.resume and Runtime.runFinalizersOnExit Deprecated?     If the untrusted module running in a separate thread does not mess with locks of the application, only at worst with its own locks, then Thread.stop might still be the best option.

    Pro/cons of Thread.stop

    • (+) easy to use
    • (+) communication between trusted and untrusted code is easy
    • (-) deprecated
    • (-) possibly unsafe in some very specific situation that must be assessed first
    • 0