0

I have a client application and a server application. The server, using JNA, is a wrapper for some dll's I need to use because and long story short there is not enough memory to run both the client and server logic in a 32-bit JVM, hence the separate applications.

I need to be able to share memory between these two applications - specifically, I need to be able to send pointers from one to the other and vice versa. I know that I can execute the runnable JAR for the server from within the client jar - as a separate process. But is it possible to execute it as part of the same process, just on a different thread? That way I might be able to send pointers from one to the other.

Here's a bit of background:

Sending a JNA Pointer from one Java application to another Java application

Community
  • 1
  • 1
xc938
  • 45
  • 4
  • So you say you are using a client and a server because the address-space is too small to contain everything - and now you are asking how to have both run in the same address space. Doesn't something about this strike you as odd? – piet.t May 15 '17 at 11:39
  • Well the client is currently running on 64-bit jvm (though it can run on either) - maybe a better question might have been is it possible for a 64-bit jar to start a 32-bit jar under the same process? I'm not exactly sure how it works. @piet.t – xc938 May 15 '17 at 11:49
  • Don't think in terms of 32- and 64-bit jars - there is no such thing. All you are talking about is 32- and 64-bit processes/address-spaces using 32- or 64-bit dlls/sos. – piet.t May 15 '17 at 11:54

1 Answers1

2

Yes it is possible. Sort of.

  1. Create a new classloader for the JAR file.
  2. Using the classloader, read the MANIFEST.MF resource and extract the name of the JAR's main class.
  3. If there is a class-path attribute, parse it and create the corresponding classloaders.
  4. Use the classloader(s) to load the main class.
  5. Lookup the Method object for main(String[])
  6. Use Method.invoke(...) to call it with the appropriate "command line" arguments.

The problem is that when you do this the application that you have started will share the standard i/o streams with the original one, as well as things like the system properties, default charset, default timezone and so forth.

And I don't think this is going to solve your "not enough memory" or "not enough address space" problems.

And finally, a 64 bit JVM cannot load 32 bit DLLs or vice versa.

One possible alternative might be to use shared memory:

Community
  • 1
  • 1
Stephen C
  • 698,415
  • 94
  • 811
  • 1,216