Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Oracle and OpenJDK are just two JVMs.

I know at least the following JVMs

Oracle JVM

OpenJDK JVM

Metro JVM

IBM JVM

Aonix JVM

Cacao VM

Squawk VM

Jikes VM

VMKit

BlueRay VMs

Excelsior JET Java native compiler

GCJ native Java compiler

Aonix Perc Java compiler

... (many many others)

I doubt every single of the above implementations does threading the same way.



So have you checked if any of these do what you claim they could do?


And you have done it?


Why would I? I said none of the implementations I know of do what you say. If you do know an implementation that does, then please tell me which one.


No you did not. You stated that is not possible in Java at all regardless of the implementation. I don't see any mention of " none of the implementations I know of" on your comment.

<quote> That's not true at all. Each goroutine has its own variable sized stack whereas Runnable objects in Java don't have a stack of their own. They use the thread's stack. So as long as a Runnable uses its stack (that is the run() method hasn't finished), the thread cannot be used by other Runnables.

So, in Go you can have thousands active function invocations (i.e tens of thousands of stack frames on thousands of stacks) at the same time and they do not occupy thousands of threads. You can't do that in Java. </quote>


You are being deliberately dense. If no existing JVM gives runnable objects their own stack, then it's impossible for a java developer to create thousands of threads (without creating their own JVM, which is totally unreasonable 99% of the time). It's a practical impossibility. Is that so much worse than a technical one?


I said it here: http://news.ycombinator.com/item?id=4707344 12 hours ago in a direct reply to your question.


I am really sorry for my reaction and excuse myself for it.

I have missed that and got carried away in Internet discussion style.

Sorry about that, somehow I got it wrong and blindly carried on discussing nonsense without thinking any longer about it.


That's OK, it's been a perfectly civilised debate after all. You're making a fair point insisting on a distinction between implementations and the spec. My initial posts were very unclear in that regard.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: