views:

928

answers:

4

A customer requires a preview of a new feature of our product. They asked to have that feature sent to them in a jar file (like a patch). There's no problem with including the new classes in said jar file. However, an existing class was modified, which is needed to integrate the new feature. They just want to add this new jar file without having to update the core classes of our product. So, the question is: is it possible to override an already existing class using a separate jar? If so, how?

Thanks in advance.

+5  A: 

There's a chance it'll work if you put the new jar earlier in the classpath than the original jar. It's worth trying, although it still sounds like a recipe for disaster - or at least, really hard to debug issues if somehow both classes are loaded.

EDIT: I had planned to write this bit earlier, but got interrupted by the end of a train journey...

I would go back to the customer and explain that while what they're asking is possible, it may cause unexpected problems. Updating the jar file is a much safer fix, with much less risk. The phrases "unexpected problems" and "risk" are likely to ring alarm bells with the customer, so hopefully they'll let you do the right thing.

Jon Skeet
in my experience, classes earlier in the classpath are reliably loaded, while later versions are not.
Cogsy
Yeah it should work, but it is still a pretty goofy way to update some classes
matt b
And dependencies on changed interfaces may still burn you. Also, a complex classloader structure may cause even the classloading to fail if all of the involved classpaths aren't updated.
Darron
if this is a planned way to deploy updates, be very careful with long classpaths. Some platforms have limits on the length of the command line. I think modern OS are relatively long but old maybe 256 or 1024 characters
basszero
+1  A: 

Yes, it may be possible, by putting it earlier on the classpath than your original jar. However, relying on the ordering of your classpath is not always going to lead to happiness. I'm not sure if it is even documented in the Java Language Spec; if not, then it's going to break for different JVMs and even different versions of the same JVM.

Instead, consider quoting a realistic time frame to integrate the new feature into the current codebase. This is perhaps not the answer you're looking for.

jamesh
+2  A: 

Yes and no, it depends on your environment.

If you use, for example, OSGi and have your versions under control, it's just a matter of installing a new bundle with the exported package at a higher version (assuming your version ranges are lenient enough).

If you use plain old Java with no fancy custom class loading, you should be good to go putting it earlier on your class path (as others already mentioned).

If you do have custom class loading, you'll need to make sure that all the classes that your 'patched' class needs, and indeed the entire transitive dependency hull, is visible from the class loader which is loading the patched version, which might mean you need to ship the entire application, worst case.

roe
A: 

All of the answers that stipulate putting the updated classes before the ones they are replacing in the classpath are correct, provided the original JAR is not sealed.

Software Monkey