Hi!

I'm looking to be able to add a user created extension to a program I'm making. The extension should be able to execute on it's on accord, then pass control back to the program when it's done.

So, Say I click a button (it's got a GUI on it), I'd like it to now pass control to a *.jar, so that I can add things to the program after the user has a copy.

I was thinking that I could somehow store the paths to the jars in a .txt, but that's easier to do, this is the hard part.


Thanks in advance,

JT

Well, you probably don't really want to load the *jar* itself, you want to load one or more classes that happen to reside in the jar. In that case, you need to have that jar on your java classpath so that the JVM can find that/those classes in the jar file. It's the same concept with the Java classes you use every day (such as String, Array, etc.) which reside in the rt.jar file of your java/jre/lib directory.

Maybe:
Create a dummy/stub version of a user created extension(ie with all the right class name & method signatures, but empty methods). You'll need this to compile your own program anyway (unless you get into heavy lifting with Reflection). When you build your distribution package, keep the .class file for your dummy extension separate from the main jar. Now the user just has to replace your dummy .class file with their own version.
(If the extension requires multiple classes, use a separate .jar rather than just a .class)

On the other hand
If there's no need for any interaction between your app and the extension you can just use ProcessBuilder to execute any other runnable jar in its own VM

hmmmm... both of those ideas are very doable.... though I have not a clue how to run a jar in a Virtual Machine..... Isn't there a class that can do such a thing?

yes there exist ClassLoader that returns declaredMethods and declaredField, but its little bit complicated

... I have not a clue how to run a jar in a Virtual Machine....

Forget the VM fro the moment. With ProcessBuilder you can run anything that runs from a command prompt - including javaw -jar ...
Only problem is that by running a second copy of javaw (the original program being the first javaw) the new and old Java programs will be running in separate environments (VMs), and won't be able to share data etc easily.

That would be just fine for my purposes, and if I needed to share data, I could write to a file... right?

Use a file for one-way passing, use a Socket connection for two-way real-time data passing. But if it's going that way I would prefer the dummy/stub class approach that gives full method calling and variable sharing between the host and extension classes/jars

I'm not sure I understand. I have about 3 months Java experience, but 1.5 years programming experience (C++ (mostly), C, JavaScript, HTML).

Sockets - like you use for internet comms, but just using localhost. Make the IP connection then open input/output streams in bith directions for real-time data transmission. Its the easiest platform-independent way for two separate java apps to communicate.
Stub classes - see my second post

Perhaps if you can explain more about what these extensions are for, and how they will be used (in particular, what info do they need to share with the main app), I can be more specific about how best to do it in Java. I'm off now, but I'll check back tomorrow morning.

Essentially what I'm doing is a thing that would allow people to have a platform that can launch any of the applications (*.jars) that people load into the application (via the path of the jar) when it's ready (the app knowns where the .jar is), then the application will launch it.

This will have a gui, but that's the easy part.

Nope, my app just needs to launch them and then close them when the user says to (the X button on the user made app). It might be nice if my app could force close them (if they are getting crazy), but that's not a requirement.

Hmmmmm... After looking in the API website for Java, I can't really understand the stuff there... Can someone explain this to me (preferably in rather basic terms!)

This article has been dead for over six months. Start a new discussion instead.