One Thing I Really Hate About the JVM

He shouldn't hate the JVM, he should hate his lame system. Rule #1 is "Never trust students' code".<p>One of the strengths of threads is that they don't have strong protection. If he wants runtime safety like that he should learn what a process is.

Wouldn't a process-based architecture be more suited to what he's doing (running arbitrary code)? It'd give you the chance to lock it down tightly if you wished within the OS itself, on top of the JVM security.

Easy solution: He should just run a static analyzer on the code first to see if it will terminate before he executes it.

1) if a student wants to pull an exploit they can, whether its in a process or a thread. The security angle just isn't there.<p>2) look at the docs for @deprecated: <a href="http://cupi2.uniandes.edu.co/web/javadoc/j2se/1.5.0/docs/api/java/lang/Deprecated.html" rel="nofollow">http://cupi2.uniandes.edu.co/web/javadoc/j2se/1.5.0/docs/api...</a> "A program element annotated @Deprecated is one that programmers are discouraged from using, typically because it is dangerous, or because a better alternative exists. Compilers warn when a deprecated program element is used or overridden in non-deprecated code."<p>It says it is dangerous, and says nothing about it being removed in a future release.<p>That's the really big misunderstanding here. @deprecated as an API annotation does not mean "going to be removed in a future release".<p>Go use deprecated functions and be pleased when the compiler warns you nicely.

What language or VM <i>wouldn't</i> this architecture be a problem in?