I was thinking (in fact I kind of already implemented it) about using a proxy (java.lang.reflect.Proxy) for the remote invocations. This will work as a kind of adapter, which will hide all RemoteExceptions and make the Remote interface look exactly like the Local one.
My DB interface does not throw IOException, so my remote interface cannot extend the local interface (I have a services layer which looks kind of similar to an EJB, that's why I'm talking about remote and local).
The idea is - if the client is running in standalone mode, it will use the local implementation. If it runs in remote mode, it will use this proxy that, through a custom InvocationHandler, will sort out any RemoteExceptions and make my remote object look as if it implemented the local interface.
My only problem is, what to do with RemoteExceptions which have a null cause (if there are any). If there's a cause, I throw it from the proxy's method invocation. If it has no cause - I throw a runtime exception (for now). Do you have a better idea, what to do with them? Or maybe it is impossible to get a RemoteException with null cause?
What do you think about this approach? Are we allowed to use the java.lang.reflect.Proxy (I did not see it being banned in the instructions...)? [ November 08, 2008: Message edited by: Alecsandru Cocarla ]
My design was very similar to yours and I passed with maximum grade in all the sections (except GUI design). I did not use the proxy class but I constructed my own implementation to build this adapter. The adapter caught the RemoteExceptions and wrapped them into a not checked exception build by me which were launched if it had sense. This way the adapter could implement the same interface than the local implementation but the "remote" exceptions were not lost. I documented this solution in detail and the Sun examiners seemed to be happy about it.
Iván Párraga García
SCWCD 5, SCJD, SCJP 5, MySQL 5 DBA