

One Thing I Really Hate About the JVM - Ainab
http://whiley.org/2011/04/15/one-thing-i-really-hate-about-the-jvm/

======
neckbeard
He shouldn't hate the JVM, he should hate his lame system. Rule #1 is "Never
trust students' code".

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.

------
mattgreenrocks
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.

~~~
hollerith
Good one: even if he cannot stop a thread, he can sure as hell stop the OS
process in which the JVM runs. So give each student's program its own JVM or
at least explain to the reader why that is not a satisfactory fix.

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

~~~
tansey
This is provably impossible in the general case [1] and almost impossible in
his specific case. It's _extremely_ difficult to know if/when a program will
terminate using just static analysis.

Edit: Why the down vote?

[1] <http://en.wikipedia.org/wiki/Halting_problem>

~~~
Adrock
The down votes are because it was a joke, punctuated by the "easy solution"
preface. The author is almost certainly aware of the halting problem.

------
willvarfar
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.

2) look at the docs for @deprecated:
[http://cupi2.uniandes.edu.co/web/javadoc/j2se/1.5.0/docs/api...](http://cupi2.uniandes.edu.co/web/javadoc/j2se/1.5.0/docs/api/java/lang/Deprecated.html)
"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."

It says it is dangerous, and says nothing about it being removed in a future
release.

That's the really big misunderstanding here. @deprecated as an API annotation
does not mean "going to be removed in a future release".

Go use deprecated functions and be pleased when the compiler warns you nicely.

------
newobj
What language or VM _wouldn't_ this architecture be a problem in?

