Get list of classes present in an applet's Jar file?

Question

I have an applet for drawing diagrams, which is bundled in a jarfile together with classes for each type of element in the drawing (e.g. a class for drawing 2-input NAND gates, a class for J-K flip-flops, and so on). When I add a new type of drawing element I have to modify the applet to add the new class to the applet's "Insert" menu to allow the element to be inserted. What I want to do is to search the jarfile containing the applet for any classes derived from DrawingElement and add them automatically to the Insert menu when the applet is inited. I presume this would require using getClass().getClassLoader() to get the class loader that read the JAR file, but from there it would seem I need to know the name of the resource to load. Is there a way of browsing the list of resources in the JAR file?

Answer 1

AndrewThompson64 wrote:
That 'modify the applet' is not strictly necessary. The list of menu items and classes might be passed to the applet as applet parameters, or as a property file or XML (or whatever) that defines the available elements.I could do this -- I'm just trying to avoid getting the list out of step with the contents (or if you prefer, I'm just being lazy!).
Is there a way of browsing the list of resources in the JAR file?Yes and no. You might try this general strategy (untested).
1) Gain an URL to a resource in the Jar in which the plug-ins exist.
2) Parse that URL for everything before the '!' symbol to get an URL for the Jar itself.
3) Get an InputStream from the Jar via URL.openStream().
4) Get a ZipInputStream by wrapping the InputStream.
5) Iterate the ZipEntry(s) to identify classes in the correct package, and store them in a collection of some type.
6) Iterate the collection and check each one for extending DrawingElement, using reflection.
I am guessing step 6 will require the applet to be trusted.Sounds plausible, and I'll give it a whirl. However, I hadn't thought about the "trusted" bit of this; maybe I can just create new instances and cast to DrawingElement, ignoring any that throw exceptions. I'll have to give it a go and see what happens.
BTW - once you have the right classes, how do you get the screen name of them? Is the name defined in one of the attributes of a DrawingElement? What prevents name clashes?Plan A: I have a getIdentification() method that returns a string identifying the element, but I have to keep this unique the hard way (by hand).
Plan B: use the class name with some prettification (e.g. have a class _2_input_NAND_gate which gets displayed as "2 input NAND gate") so that the compiler does the work of keeping it unique. Not sure I like this, though.
Many thanks for your help.