This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Native threads generally map to either a native OS/System thread or LightWeight Process. This means that when you create a new thread in Java, you get a new OS thread. In the case of Green threads, java creates and manages it's own virtual threads which don't have a corresponding OS thread. In this case Java and the application(s) it's running all effectively run in a single OS thread. So you're right, they won't take advantage of parallelism.
Green threads appear to be an artifact of the original Green Project, which was trying to design a hand-held computer based on the Sparc chip. So the original Java (the called "Oak") VM was written to run directly on the Sparc, without Solaris/SunOS. Because of that, they had to roll their own thread support. The project to transform Oak into Java had very limited resources initially, they only did the bare minimum to port the language to desktop computers (as anyone who ever used the 1.0 AWT can attest). So they kept Green threads in the Solaris version because it worked, kind of. The Green threads implementation used all kinds of tricks to make sure that I/O never blocked the single native thread. When these tricks failed, the VM would hang until the I/O request completed. BTW, it turns out that a one-to-one mapping of VM to native threads isn't optimal either, because native threads tend to have quite a bit of overhead. The current production release of the Solaris VM uses multiple native threads, with each native thread servicing a number of VM threads. John Brewer Jera Design