Applets, unless especially privileged by the user, run in a sandbox that prevent them from interacting with the local OS [1]. They certainly cannot run EXEs, again, unless the user consents.
In theory the Applet sandbox works really well. It's an extremely secure environment that's been deployed widely in the most demanding conditions -- think banks and governments. In practice the Applet security model encountered the following problems:
(1) Users are really, really dumb. They are happy to grant escalated privileges to the some 3D farming game they stumbled upon on the internet. Users will literally click on anything you tell them to. [2]
(2) Getting users to upgrade Java was terribly difficult. This meant when a real security flaw was discovered it might hang around for years and years and years. There was no mechanism to force users to upgrade Java or to actively disable Java installations proven insecure.
In theory the Applet sandbox works really well. It's an extremely secure environment that's been deployed widely in the most demanding conditions -- think banks and governments. In practice the Applet security model encountered the following problems:
(1) Users are really, really dumb. They are happy to grant escalated privileges to the some 3D farming game they stumbled upon on the internet. Users will literally click on anything you tell them to. [2]
(2) Getting users to upgrade Java was terribly difficult. This meant when a real security flaw was discovered it might hang around for years and years and years. There was no mechanism to force users to upgrade Java or to actively disable Java installations proven insecure.
[1] https://docs.oracle.com/javase/tutorial/deployment/applet/se...
[2] https://www.trustedsec.com/2013/04/java-7-update-21-applet-s...