One Thing I Really Hate About the JVM
whiley.org
One Thing I Really Hate About the JVM
1–10 of 11 posts
Re: One Thing I Really Hate About the JVM
#2He 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.
Re: One Thing I Really Hate About the JVM
#3Wouldn'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.
Re: One Thing I Really Hate About the JVM
#4What language or VM wouldn't this architecture be a problem in?
Re: One Thing I Really Hate About the JVM
#5Easy solution: He should just run a static analyzer on the code first to see if it will terminate before he executes it.
Re: One Thing I Really Hate About the JVM
#6Easy 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.)
Re: One Thing I Really Hate About the JVM
#7Easy solution: He should just run a static analyzer on the code first to see if it will terminate before he executes it.
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?
Re: One Thing I Really Hate About the JVM
#81) 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.
Re: One Thing I Really Hate About the JVM
#9Easy solution: He should just run a static analyzer on the code first to see if it will terminate before he executes it.
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.
Re: One Thing I Really Hate About the JVM
#10Wouldn'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.