Yes, if you System.exit(), then all threads (even native ones) will stop, because System.exit() blows away the process (in the JVMs that I know, anyway).
However, your Java program generally should not System.exit() unless it really has to. When you System.exit(), all threads stop, regardless of what they were doing at the time. Also, using System.exit() makes your code unsuitable for re-use in a Web applictation or other application server, because System.exit() will kill the whole process, not just the particular bit of the process that's running your particular application.
Instead of using System.exit(), you should arrange for all your non-daemon threads to exit cleanly. Perhaps you can use Thread.interrupt(). Perhaps you can have some sort of global shut-down flag that all threads check every now and then. Perhaps some of your threads should be daemons, so they do not delay JVM shut-down.
If your application uses graphics (Swing/AWT), then there is an extra issue. You need to make sure that none of your windows has the default parent. Instead, you should create your own dummy Frame as a parent for all of them. When it's time to shut down, you should dispose() that Frame. Then the application can shut down cleanly, without System.exit().
Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma.
How a JVM implements its threads internally is an implementation detail and can vary from one JVM to another. When the JVM shuts down, it doesn't have to call any Java code, as the JVM itself is the thread manager (or simulator). Java Thread objects are mere abstractions of JVM threads.
...and JVM threads are generally abstractions of operating system threads, which are in turn abstractions of physical microprocessor threads.