One Thing I Really Hate About the JVM (opens in new tab)

(whiley.org)

12 pointsAinab15y ago10 comments

10 comments

10 comments · 5 top-level

dlsspy15y ago· 4 in thread

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

tansey15y ago

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

Adrock15y ago

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.

willvarfar15y ago

+1 Indeed. Its the classic problem.

devinj15y ago

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

mattgreenrocks15y ago· 1 in thread

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.

hollerith15y ago

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.

neckbeard15y ago

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.

willvarfar15y ago

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.

newobj15y ago

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

j / k navigate · click thread line to collapse

10 comments

10 comments · 5 top-level

dlsspy15y ago· 4 in thread

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

tansey15y ago

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

Adrock15y ago

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.

willvarfar15y ago

+1 Indeed. Its the classic problem.

devinj15y ago

mattgreenrocks15y ago· 1 in thread

hollerith15y ago

neckbeard15y ago

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.

willvarfar15y ago

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.

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.

newobj15y ago

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

j / k navigate · click thread line to collapse