How to isolate your program from calls to a “bad” API?

Question

When I developed a piece of (academic) software using Java, I was forced to use an API that was rather badly implemented. This means that calls to this API for a certain set

Answer 1

I would recommend the use of a separate process. There is essentially no safe way for one thread to kill a second thread in Java unless the second thread is periodically checking to see if it has been interrupted.

The ideal solution would be to use isolates. An isolate is essentially a private virtual machine that a Java app can create, managed and communicate with. In particular, the parent app can safely kill an isolate and all its threads.

Reference: JSR-000121 Application Isolation API Specification - Final Release

The problem is finding a JVM that supports Isolates.

Answer 2

I'm a big fan of separate processes for this kind of thing.

Spawn a sub process and wait for results.

If the API is non-deterministic, put the timer thread in a wrapper that makes the bad API into a main program.

That way, the subprocess always ends within the given time. It either produces a useful result or a system exit code that indicates failure.

Answer 3

The best thing to do would be to re-implement the API in question. However, as you say, that's a very heavy weight and probably out-of-scope solution.

The next best thing would be to wrap the API if possible. Basically, if you can determine in advance what it is about the datasets that causes failure you could reject calls to guarantee determinism. It doesn't sound like this will work for you either, as you suggest that repeating a call with the same dataset will sometimes terminate when it had infinitely looped in a prior invocation.

Given the above options above aren't available:
I think your current thread solution is the best of the bad choices. Spinning up a process for a method call seems way too heavy weight to be acceptable from a performance point-of-view, even if it is safer than using threads. Thread.stop() is very dangerous, but if you religiously prevent any locking you can get away with it.

Answer 4

Both @S.Lott and @Stephen C's answers are spot on with regard to how to handle this type of situation, but I'd like to add that in a non-academic environment, you should also be looking to replace the API as soon as practical. In situations where we've been locked into a bad API, typically through choosing a vended solution for other reasons, I've worked to replace the functionality with my own over time. Your customers are not going to be as tolerant as your professor since they actually have to use your software (or not!) instead of merely grade it.

There are certainly situations where using duct tape is an adequate choice to solve a problem. When it results in such poor behavior as you describe, though, it's best not to rely on it too long and start working on a real repair.