When you push an object to the Lua interpreter from J/S and create a global reference to it, a Lua script that is then run and accesses the object will access the same object as in the J/S side, not a copy of it. So once the script ends, the Java/Scala sees the object with state (data members) as modified by the Lua script. If the J/S then modifies it, and another script run that accesses that object, that script will see the new state as modified by the J/S.
So there is no mimicking when calling methods: a method is a function bound to an object, so calling it from Lua or from Java/Scala causes the same object (the same memory block) to be accessed.
However, mimicking is required when constructing: if you construct an object in J/S, you must explicitly push it to the Lua interpreter for it to become available; if a Lua script run by the interpreter creates a new object, the J/S must pull it (via a global variable that references the object). For disposal, I wager that the object will be automatically finalized when there are no references left to it on either side (J/S or Lua).
So all you need to do is ensure that the objects you care to have in both environments are pushed and pulled on the J/S side (the Lua side is "slave"). I don't think it is a good idea to automate this: explicitly push/pull only what is required on both sides, no more no less.