Using Modified Third Party Jars in BB

BBj is distributed with a number of third-party jar files that it needs to run. Some BBj 17.xx examples are: JasperReports jasperreports-javaflow-6.4.1.jar, ASM asm-6.0.jar, Byte Code Engineering Library bcel.jar, and BouncyCastle bcprov-jdk16-146.jar. BASIS always attempts to release BBj with the newest versions of this set of jars that together make a consistent set based on the version of Java supported in BBj. Thus, BBj is not always able to move immediately to the newest version of every third-party jar file released.

BBjIndex.jar is the index jar that lists and orders all of the BBj jars and any third-party jars that are critical to BBj’s server, while JnlpIndex.jar fills a similar role for BBj JNLP clients. Inserting modified versions of any of these critical jar files into BBjServices’ basis.java.classpath ahead of BBjIndex.jar (attempting to override the distributed version) is not supported. Since BBj classes rely upon the original versions for functionality, overriding a distributed jar could cause arbitrary errors in other third-party libraries, in BBj, or in  BBj client programs.

 

BBj also does not support running with either a different released version or any user-modified version of the jars identified for a particular release set (as an example, for 17.x, see http://documentation.basis.cloud/BASISHelp/WebHelp/b3odbc/bbj_17.x_classpath_overview.htm). 

For a good “generic” discussion of why modifying third-party library code is not recommended, see this blog article: http://www.lonecpluspluscoder.com/2014/12/29/im-strongly-opposed-modifying-third-party-library-code/. Most of the arguments revolve around the issues that anyone would see once they begin to try to maintain such a path – any update of a library or jar in the dependency chain (such as JasperReports’ chain) can cause errors, mostly because of undocumented internal dependencies in that chain in conjunction with future maintenance changes anywhere in that chain.