Forward class reference in Java?

[Ken]

Hi. Let's say class A only references class B without using any of
its methods (e.g., it takes an instance of B as a parameter and sticks
it on a collection as an object). In C++, I would have A's header file
contain a forward reference to B (as opposed to including B.h). That
way A wouldn't have a dependency on B's method signatures.

Is there an equivalent way to do this in Java?

Thanks for any input,

Ken

 

[Roedy Green]

Hi. Let's say class A only references class B without using any of
its methods (e.g., it takes an instance of B as a parameter and sticks
it on a collection as an object). In C++, I would have A's header file
contain a forward reference to B (as opposed to including B.h). That
way A wouldn't have a dependency on B's method signatures.

Is there an equivalent way to do this in Java?

There is no problem. Java handles forward and circular references all
by itself. All you have to do is put both classes on the javac command
line when you first compile them.

 

[kk_oop]

There is no problem. Java handles forward and circular references all
by itself. All you have to do is put both classes on the javac command
line when you first compile them.

Is the compiler smart enough to know that a change to B's methods'
signatures will not require A to be recompiled? Note that I would have
A contain a reference to an interface version of B to prevent A having a
dependency on B's implementation.

Thanks again,

Ken

 

[Roedy Green]

Is the compiler smart enough to know that a change to B's methods'
signatures will not require A to be recompiled? Note that I would have
A contain a reference to an interface version of B to prevent A having a
dependency on B's implementation.

Javac is not perfectly intelligent in figuring out what needs to be
recompiled. Once it gets loaded is it so quick it barely matters.

You can study the dates on the class files to see what it recompiled.

These rules seem to work fine for me:

1. don't worry about recompilation. Let the IDE handle deciding what
to recompile.

2. If you are suspicious it is not recompiling when it should, delete
all the class files to force it to recompile the world.

3. Before any major test or release, delete all the class files.


If you had a truly giant project with most of it stable, you might
want to use ANT to try to be cleverer about what to recompile. I have
yet to be convinced that ANT has any practical use in recompilation on
single person projects. I'd think the better way to handle the
problem would be to feed all the *.java files to Javac.exe via the
main class interface and let it figure out what needs recompilation.

I don't think anyone has a perfect way of deciding what needs
recompilation. A theoretically perfect algorithm does exist --
tentatively compile everything and note what changed, then recompile
only those. You can simulate that with untouch if your desire is to
avoid distributing class files that have not really changed.

see http://mindprod.com/projects/untouch.html

 

[Roedy Green]

3. Before any major test or release, delete all the class files.

The secondary reason for this is to ensure you have source for all the
class files. If you delete a source file, the class file can hang
around and keep and old reference happy, that will fail the next time
you delete all class files. Note you should delete all class files,
not just recompile everything.