Maybe I'm misunderstanding here, but it sounds like you're initially
asking whether the Java compiler can perform a compile-time decision about
which statements to include, and then later say you want the behaviour to
depend on run-time information.

   Is this correct? If so, then you want a decision to be made before the
information is available to make it. Instead, you should write code that
tries to load one class (or set of classes) and if that fails, instead try
to load a second class (or set of classes).

   - Oliver

imports are only for compiler there.
You may import everithing you want, it does not change class file.

Import both lots of classes, if you like, but wrap the creation of the
object in a try/catch block

However, if the classes have the same names, you can't import them, and
will have to use fully qualified names when creating the objects.

I haven't studied the comm API, so I'm not sure if there is an interface
that you can code to? Otherwise, you may want to wrap the two different
implementations in your own interface to hide the differences.

e.g.
interface MyCommInterface

// the methods that you need

interface GNUCommImpl implements MyCommInterface

interface SunCommImpl implements MyCommInterface

Then, e.g. in GNUCommImpl

try {
whatever = new gnu.io.Whatever();
} catch (ClassNotFoundException cnfe) {
// whatever
}

Or, detect which class is available, and instantiate the corresponding
class of your interface.

Rogan

On Fri, 28 Oct 2005 14:13:49 GMT, "U. George"
<support@jgpsDOTgatworksDOTcom> wrote, quoted or indirectly quoted
someone who said :

I too have run into that.  It is one of few instances where you get
nostalgic for C++ macros.

The way Sun handles that in cases like JCE, JMF  etc is to provide in
interfacing plug-in class.

At run time you give it the name of the 3rd party  library you want,
and it hooks it up.  Your application code always deals with the Sun
interface class.

You need a lot of glue, and there is an extra layer of run-time
indirection, and you can't as sure at jar build time you ensured all
was present, but it is quite open ended. You can keep on adding even
more implementations with no change to the applications.

My suggestion:

Write two classes, one that uses package A, and the other that
uses package B. Include both in your distro.

At run-time, try and create your object that uses A, and if that
fails create an instance of the B using class instead, and use
that. It would help if the constructors of your class try to use
the A or B package so that the constructor fails if the package
is missing, rather than further down the road.

Steve

U. George <support@jgpsdotgatworksdotcom> wrote or quoted:

"Yet"?

I don't see why it should ever have that facility.

Have two different libraries? Use two different interfaces in two
different classes and then choose which class you instantiate.