On Wednesday 13 August 2003 19:04, Tal Achituv wrote: > I'm looking for a solution for internal affairs :-) not with clients... > > we do that class changing thing allot here, and looking for a way to > resolve this "dependency" issue.. I have the sources.. no need to > decompile...
> here's the problem: > > I have to supply a patch for a software build 18, and am currently working > on build 22 of the same software. > > I wonder if I can just give them the class from the b22 and put it instead > the patch requiring class of the b18... > > Now I need to wait until runtime to see if this class really fits... :-) I don't think I understood the issue here : you simply want to know if your class from build 22 will work with the system from build 18 ? if you have a decent configuration management (versioning and building system) simply reconstruct build 18 somewhere safe, put in the new class and run it - see what the JVM complains about. another options is simply to simulate build 18 environment while you compile - set the compile class path to only include source versions from build 18. then the compiler itself will tell you what you are missing. while it is true that "linking" only occures at run time, the compiler tries its best to make sure you have all your linking dependencies in place by checking them at compile time. As Amos noted - this is only good if you're not using dynamic class loading. if you do, then all bets are off and you are on your own. -- Oded ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
