maybe you could do it with multiple classloaders.
You start up your main App with the hole game simulation, controllers and so on. And then create an own classloader for each player, which does only have classpath access to some interface classes.
Thats just a wild guess I would probably investigate a bit if I would want to do something similar.
Thx, for your answer. Yes, I have heard of this. Could be a usable isolation in the first place, but I would like to know, if there is really impossible to find all the objects loaded by other classloaders. For example, Eclipse's debugger can do "heap walking" and find all instances of a type. I don't if that is limited to a classloader.
Anyway I don't think that anyone implementing a player will go so far, so this is a bit academic on that level, but I would like to know how far I can go.
On the other hand, can't you disallow reflection and so on when a security manager is set?
Yes, I think the default SecurityManager / policy (at least partially) prevents usage of reflection, but what if some part of the game uses or must use reflection? I don't know yet, if I can write a policy so that some part of the program is allowed to use reflection while another part can not do so.
As far as I remember e.g. there where some problems with Apache Tomcat when activating the SecurityManager. Persistence frameworks, don't they frequently use reflection? Just examples where IMHO you can shoot yourself into the foot, when disabling reflection completely, but I don't know all that exactly.
To make it clear: I did not use reflection myself in the program. Possibly there is some reflection going on under the hood (e.g. by akka), but I don't think so. Also I don't make use of a persistence framework,yet. So again, this is a bit academic, but beyond finding a practical solution for implementation I would like to understand
So I am a slave for my passion and I am forced to years of research again.