The 3rd party could do the same thing in code not extended from your library, too.

You are asking how to prevent others from writing bad code.

You really can't.

You can create a sandbox (perhaps using a combination of ClassLoaders and
Threads) to run others's code for certain applications, such as for
instructors grading programming instructors.  Monitoring threads can "decide"
if a thread has gone on "too long" and interrupt it.

When writing APIs for extension one can do certain things to restrict clients'
abuse.  You can declare methods final, preventing them from being overridden.
 Keep all instance variables private.  Do not call overridable methods in
constructors.  Make them derive from an abstract class that ensures key
invariants.

You cannot generally prevent bad code, but you can mitigate it by firing bad
programmers and continuing to train the good ones.

The 3rd party could do the same thing in code not extended from your library, too.

You are asking how to prevent others from writing bad code.

You really can't.

You can create a sandbox (perhaps using a combination of ClassLoaders and
Threads) to run others's code for certain applications, such as for
instructors grading programming assignments.  Monitoring threads can "decide"
if a thread has gone on "too long" and interrupt it.

When writing APIs for extension one can do certain things to restrict clients'
abuse.  You can declare methods final, preventing them from being overridden.
 Keep all instance variables private.  Do not call overridable methods in
constructors.  Make them derive from an abstract class that ensures key
invariants.

You cannot generally prevent bad code, but you can mitigate it by firing bad
programmers and continuing to train the good ones.

Simple answer: you don't.

In practice though this is a rarely if ever seen scenario.  You'd simply
stop using such a library, wouldn't you?

You are worrying too much - unless you want to create a system that
should download arbitrary code from /somewhere/ and be robust against
bugs and malicious attacks.  But then you also need to address a lot of
other issues (preventing disk accesses etc.) and you probably want to
look into Java's security model.

Kind regards

    robert

There are lots of ways of causing DoS from mobile code. Applets are not
immune from it. The only effective way of dealing with such code in Java
is to start it in a new process, which can then be sacrificed. The
typical way of dealing with such things is not to run code that attempts
a DoS whether deliberately or not.

Tom Hawtin