Local mode architecture

[aquaphile]

I am having trouble deciding which architecture to use to accomodate the "local"/"non-networked" requirement. I had the application complete as a networked client/server architecture, and now I am retrofitting it. According to my test requirements:
i. The application must be capable of running in local mode. No networking can occur in local mode; no sockets should be created.
ii. The application must run in a single JVM when in local mode.
I find these requirements silly; however, I must design for them nonetheless.
Req (ii) is the real "gotcha". Naturally, I don't want to create a customized VM manager (nor do they want that, I imagine). Therefore, here are the options as I see them:
A) Create a single application jar, containing all the client and server classes. The user can specify the startup configuration via command line system properties (-Ddb=<value> .... I prefer using system properties rather than application arguments since the latter is not portable to MacOS). Based upon the supplied propertied (db, port, server), the application launches as either a local client/server, networked server, or networked client.
- PROS: single jar eases deployment, Runs in a single VM if local mode is chosen
- CONS: deploying code that may not be used (i.e. gui code isn't needed if running a networked server), command line choices may be confusing, confusion as to which java.policy (client or server) to use, possible security risk?
B) Create a client and a server jar. To run in local mode, the user launches each app separately. The arguments (db name to the client & a db name to the server), as a system property at the command line, let the application know to run local. Running networked would just require different args (port, server). My problem with this is HOW DOES THE CLIENT CODE FIND AND UTILIZE THE SERVER CODE? Do you use some sort of system property to find the server? Also, won't this run as 2 VMs in local mode?
-PROS: Clear separation of code in 2 jars
-CONS: slightly less confusing command-line launch, Easier to use separate policy files, How do the client and server find each other? Runs in separate VMs.
C) Create a client and a server jar that really contain all the client and server code in each. It would give the user the illusion of different packages, but in reality this is the same as option A. I could make the command line a little simpler by creating a Facade class for the respective server or client startup.
-PROS: One VM in local mode
-CONS: Least confusing command-line launch, Easier to use separate policy files, Code duplication in the 2 jars
Please give me your opinions!! This is an amazing source of frustration for me, since I don't like any of the choices. Thank you for all your help.
-Chris
[my assigment code dates from Aug-01]

[Mark Spritzler]

I only got half way through your post, but the tone makes me think that you think that in local mode you still see a server running, which is not the case.
In Local mode there is no server running at all, your client uses the data classes directly.
Mark

[Peter den Haan]

Seconded -- alternative B is out. To solve your "how do I divide the classes over jars" problem, check out the Class-Path manifest attribute. That way you can have a client jar with just the client classes, and a server jar with everything else.
- Peter

[aquaphile]

Thanks for your input!