I worry a little when concepts like automatic synchronising wrappers turn up.
The problem is that the appropriate granularity of synchronisation depends on
the meaning of the operations invoked by the API, and by their interrelations,
rather than by the boundaries between the actual methods in the API.

If the API is unusually well-defined, then each semantic operation will
correspond to exactly one method call (which is a valuable property for an API
in itself, and even more so when API calls involve moving data over a
network[*]).  But if not -- as is typical -- then automatically adding
"synchronize" to each method call will not provide the necessary safety.

In your example:

    synchronized(target) { target.doOp(); target.doOp2(); }

would be implemented by the automatic wrapper as if the code said:

   synchronized(target) { target.doOp(); }
   synchronized(target) { target.doOp2(); }

which doesn't provide the same semantic guarantees at all.

The converse of the same point is that the locking behaviour of an application
is not something that can be fully encapsulated and hidden away.  It is an
issue that can have global ramifications for the design of an application,
unless you want to risk poor performance or even deadlocks.  In non threaded
code you can (putting things in OO terms) just ask some object to do something,
and let it worry about the implementation -- so the large-scale application
architecture is not dependent on the details of how the object implements that
operation -- but that is doesn't always apply where locks are concerned, since
any held lock can potentially lock out any other piece of code.  That's not
always a problem, but where it is, I'd worry that low-level, automated
facilities would not be "intelligent" enough to do the job properly.

The greatest danger (IMO) is that the code which uses the wrapper /may/ be
correctly designed to use synchronisation properly, or it may not, and there is
no way to tell which just by reading it.  I.e. there is no way to tell
easily -- or even make a good guess -- whether the implicit synchronisation is
any of:
   + correct by carefully considered design
   + correct by unconsidered default
   + correct but unnecessarily slow
   + incorrect

That worry is greater still when there may be more than one proxy for the same
object.  In normal circumstances, multiple proxies are either a complete no-no
(which may apply in your case, though you don't mention it); or are considered
to be a normal state of affairs.   If your semantic safeness depends on the
proxies all agreeing on how they synchronise, then you may have to put more
work into that part of the design than you've shown so far (presumably the
separation of the 'target' and 'sync' objects in the wrapper API is intended to
be a step in that direction).

The only case I can think of (so far) where the automatic synchronised wrappers
might be worthwhile is if the wrapper is /only/ intended to protect the state
of the network proxy object itself, not the state of the object it is a proxy
/for/.  (In which case method-level boundaries would be appropriate -- but then
I'd sort of hope the RMI implementation would have that under control anyway).

   -- chris