FWIW, if the Java app is entirely local to the folder and is not downloaded, security attacks against it are unlikely. AFAIK. all security attacks against Java on OS X have launched via the web start plugin or the safe downloads stuff and a downloaded app, which then breached the sandbox. There's very little exposure to an account running a Java app locally, particularly if — as is typical practice — the web start plugin is disabled, and the "safe downloads" aren't automatically opened.
If the Java app is downloaded, then you may (do?) have the potential for security problems, and the most recent Java packages can whitelist certain sites as a means to reduce this. (I'm not yet ready to trust these most recent Java changes, though.)
Ownerships, protections and ACLs are the usual means of blocking access to system resources. Not profiles. Probably the safest approach is to add denials into the access control lists, but non-administrative users don't have wide write access to OS X systems; such users are already denied write access to sensitive items. If you have shared stuff, you could add an access control list entry that specifically denies access.
Tested and verified backups — in depth, and preferably offline or offsite — are also obviously important, as they're a path to recovery after a breach.
If the folks are drilling out of the Java sandbox for fun or profit, they're probably not going to be launching other Mac apps, and will be probably be headed more directly toward the Unix layer or other lower-level giblets. They'll likely also be installing stuff, if they can manage that. FWIW. (Which is also why the user running the Minecraft server daemon shouldn't be an administrator.)
You can further restrict access to the Minecraft server by restricting access to VPN'd users.
Another mechanism to partition Java is to configure it as a guest in a virtual machine. That way, there's nothing else installed in the guest, and the attacker is faced with exploiting a clean install and/or drilling out of the guest, too.