can you make reflection work with an interface

[Jason Richard]

Hi All,

Let me preface this with the following. I'm fairly new to reflection.

I was wondering if there is a good way to use reflections when implementing an interface.

I am/was trying to write some code that would only work if you had the required library, and if not ignore it.

	if (Class.forName("com.test.gui.ExtraPanel") != null)
				{
					
					Constructor constr = Class.forName("com.test.gui.ExtraPanel").getConstructor();
							
					jtp.addTab("ExtraPanel", (Component)constr.newInstance());			
				}

this part works great, but Then I realized I wanted to add an interface so

	if (Class.forName("com.test.extraGuiParts.ExtraPanel") != null)
				{
					[b]com.test.extraGuiParts.LoggerListenerI logger = new Logger();[/b]

					Constructor constr = Class.forName("com.test.extraGuiParts.ExtraPanel").getConstructor();
							
					jtp.addTab("ExtraPanel", (Component)constr.newInstance(logger));			
				}

but this won't work because Logger must exist in the main GUI project and I don't think I can reflect

public class Logger implements LoggerListenerI

since the goal was the main GUI project was to not know about the "extraGuiParts", this seems to make programming with interfaces a bit of an issue.

Is there a good standard for working with this, or is my design just flawed.

[Jesper de Jong]

So, the code that's loading the classes dynamically is not supposed to know about class Logger, but it does know about the interface LoggerListenerI?

You could ofcourse dynamically load and instantiate Logger just like you are doing with class com.test.extraGuiParts.ExtraPanel.

For example:

Class<?> loggerClass = Class.forName("com.mypackage.Logger");

com.test.extraGuiParts.LoggerListenerI logger = (com.test.extraGuiParts.LoggerListenerI) loggerClass.newInstance();

// ...
jtp.addTab("ExtraPanel", (Component)constr.newInstance(logger));

[Winston Gutkowski]

Jason Richard wrote:Is there a good standard for working with this, or is my design just flawed.

I wouldn't go as far as to say flawed but, IMO, reflection should always be a decision of last resort.

It's tricky, error-prone, often cryptic, and SLOW (up to 50 times slower than "regular" code in some cases); and you don't get any of the normal safety nets (such as type checking) provided by the language.

So, before you embark on a long reflective odyssey, ask yourself whether you really need it; and whether there might be other techniques (such as dependency injection, or even just a plain old Java pattern) that might be better for your application.

My question: Why do you think you need reflection? If it's simply to load custom classes for your runtime, then DI, or indeed a custom ClassLoader might well be a better fit.

After twelve years of using Java, I can still count on my fingers the number of times that I've needed to use reflection heavily ... but that may also be because I detest it, so I'm biased.

Winston

[Jason Richard]

Winston. My thought was to be able to drop a library into an existing project, and if it's there include the new functionality. If it's not there, don't.

Most of the new functionality would run independent of most of the other items in the existing project (with a couple minor exceptions), so the cost would be up front (I think) of create this JPanel , add it here, add a few menu items and go. All the work would be done in the newGuiParts Library. So I thought that would be fairly cost effective. I guess the real question is what sort of value add would there be, and perhaps it would be better to just always include the newGuiParts library and expose it though licensing only. Plus it's always fun to work with stuff you haven't done too much with yet.

Jesper: I don't know why I hadn't thought of just doing it as an inner class, I was more thinking of it being a stand alone class. Brilliant.

[Winston Gutkowski]

Jason Richard wrote:Winston. My thought was to be able to drop a library into an existing project, and if it's there include the new functionality. If it's not there, don't.

Hmmm, Dynamic extensions. Sounds to me like something for a custom ClassLoader (or possibly DI); not reflection.

Most of the new functionality would run independent of most of the other items in the existing project (with a couple minor exceptions)

And I hate to say, but it's those "exceptions" that are likely to bite you ITA. However, if you already have a set of interfaces that any "additions" have to implement, it might be a lot easier. Indeed, that's how a lot of custom factories for things like JDBC work.

Plus it's always fun to work with stuff you haven't done too much with yet.

Hm. To a point. And mine usually precludes reflection, because I don't want to have to write the test rigs for it (or indeed the code). Hey, colour me "lazy".

However, Jesper seems to have solved your problem without reflection (not quite sure where the "inner class" bit comes from though), so give it a try.

As with almost everything in programming, there's almost always more than one way to skin a cat.

Winston