One Thing I Really Hate About the JVM | Hacker News Reader

One Thing I Really Hate About the JVM

whiley.org

12 pointsAinab10 comments

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.

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.

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.

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

This sounds like a bad idea, but it's actually very reasonable. Students, especially in early courses, are generally taught a subset of the language that wouldn't be that difficult to check for halting. As a bonus, you could also have that program analyze asymptotic bounds to help with grading.

Still, this isn't the easy solution. The easy solution is to use a process and terminate it if it takes too long. Threads can't be reliably terminated, and especially not without accidentally ruining internal state. (what happens with locks? etc.)

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

+1 Indeed. Its the classic problem.

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.

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

What language or VM wouldn't this architecture be a problem in?

Reply on news.ycombinator.com