|
Walden H. Leverich wrote: >>Are you sure you want to do that? > No. I'm not "sure." But I think I do. :) >>You run the possibility of encountering compatibility problems >>at some point in the future if the JVM changes. > Why? No more so than for a .class file sitting in the IFS, no? Are you > suggesting that there might be a change in the JVM where IBM looked at > all the .class files in the IFS at upgrade time and changed them? Doubt > it. Assuming you used a good build tool (ant, eclipse, etc), then you can have a reasonably safe assumption that all the classes sitting in the IFS or in a jar file will be compatible with each other. If you store the class in a blob, you have to be absolutely rock solid sure that your change control procedures (including, but not limited to, change control system [speaking as a vendor]) are in place. If the interface for the class you storing in the blob changes in the calling code (which I assume is not loaded from a blob) then your application will break horribly because it will no longer be compatible with the class in the blob. If you store just the data in your database, you can version it ... and build the versioning functionality in your code ... so when the class (not stored in a blob) loads the information from the database, it can make the necessary adjustments to previous versions so they would be compatible. david
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.