www-community mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Rall <...@finemaltcoding.com>
Subject Re: Hashing it out [was: Re: Clear the air Re: ATTN: Maven developers ...]
Date Tue, 11 Feb 2003 02:02:36 GMT
Stefano Mazzocchi <stefano@apache.org> writes:

> If you use *regular* programming practices you have to do
>   import LGPLObject;
> then
>   LGPLObject o = new LGPLObject();
>   o.doSomething();
> that will
>   1) ask the classloader to find that object
>   2) allocate memory for it
>   3) create the object
>   4) invoke the object method doSomething
> This means, mostly, for legal sakes that the LGPLObject *MUST* be in
> the classloading space during compilation time.
> Now, if we use reflection, we can do
>    Class c = Class.forName("LGPLObject");
>    Object o = c.newInstance();
>    Method doSomething = c.getMethod("doSomething");
>    doSomething.invoke();
> which compiles even without having the LGPL library in your classpath.
> *BUT* programming java in this way is *FOOLISH*. Reflection was
> created to load classes programmatically at runtime, it was not
> created as a way to route around legal problems.

Integrating seems like it works best when said code implements a
non-viral API which can be imported (not certain whether there is
(L)GPL code which does this).  In such a situation, you can import the
interfaces and class-load the implementation.

  import FreeInterface;
  String className = Sytem.getProperty("FreeInterface.implementation");
  Class c = Class.forName(className);
  FreeInterface obj = c.newInstance();

FreeInterface might be something like the java.sql.Connection
interface from Sun's JDBC API.  The above allows you to avoid the
overhead associated with using reflection from pure Java code, while
still leveraging virally-licensed code.

Daniel Rall <dlr@finemaltcoding.com>

To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org

View raw message