Compile-time dependencies
Everytime a class A a "direct" dependency on class B, class B must be present when you compile class A. What things are considered "indirect" dependencies, where class A can compile without the presence of class B, and what are considered direct dependencies?
One thing I can think of is that if you use the Class class to instantiate a class, that class definition doesn't have to be present at compile time (right?). I also know that what class or interface name you specify as a parameter type or return type must also be present.
What's the general "philosophy" behind what's considered direct and indirect? There are so many different possible dependencies that I might be better off knowing the general concept than trying to memorize...
Thanks.
Any class that you refer to in your code must be on the classpath at compile time.(Note that this does not include classes that you refer to only by String literals, e.g. "com.foo.Bar")
jverda at 2007-7-12 20:39:38 >
If you compile a class with one version of its dependencies present to the compiler, but then at runtime of the application swap out that dependency with a different version, does Java recognize that it's different and that a recompile is necessary, or is it required to work just fine with the new class, provided that things remain the same?
If the latter, what kinds of "incompatible changes" would cause this application to break, and what are compatible changes?
Java won't do any recompilation at run-time.
However there's a large number of ways in which incompatibilities are detected and treated, e.g. ClassNotFoundException, NoClassDefFoundError, IncompatibleClassChangeError, NoSuchFieldError NoSuchMethodError, etc, if anything that is supposed to be there, that was there at compile time, isn't there at runtime.
Some of the things that can trigger this are:
- removal of classes (e.g. changed package or class name)
- changes in the inheritance of a class
- changes in the access modifiers of a class
- removal of methods (e.g. changes to method names)
- changes to access modifiers of methods
- changes to method signatures
- changes to method parameter or return types
- removal of fields (e.g. changes to field names)
- changes to field types
- changes to access modifiers of fields
etc etc. You could go on all day.
Some of the things that don't cause problems are:
- reordering of methods
- addition of new methods (except in an interface, or abstract methods in an abstract class)
- reordering of fields
- addition of new fields
- liberalization of access modifiers, e.g. protected to public
ejpa at 2007-7-12 20:39:38 >
Thanks for your response.
Can you change the implementation of a method provided that the signature and return type stay the same without breaking it?
Also, do incompatibility errors in methods, for example, only get thrown when that method is attempted to be called, or when the class is loaded? (i.e. if you make an incompatible change that one set of runtime operations doesn't use, will it not cause a problem in that case?) - of course that wouldn't be the case for things like changing the class or package name or class-specific things - rather, for class members.
> Can you change the implementation of a method
> provided that the signature and return type stay the
> same without breaking it?
Without breaking binary compatibility? Yes, of course, it's done all the time.
Whether or not the new implementation breaks the application is another question of course ...
> Also, do incompatibility errors in methods, for
> example, only get thrown when that method is
> attempted to be called, or when the class is loaded?
When it's called AFAIK.
ejpa at 2007-7-12 20:39:38 >
