|
jthompson@xxxxxxxxxxx wrote: > ... > I guess I should outline what I'm currently doing: > - any RPG program that wants to use Java classes calls a procedure > 'setClassPath' which sets the environment value CLASSPATH. This is good > because it means the classpath is set differently for developers and all > other users (the code within setClassPath is able to determine whethwer > it's a development or production environment). But it's also bad because 1) > once the JVM is started, all subsequent calls to setClassPath are > ineffective 2) developers aren't always remembering to code the call 3) > everytime I want to evaluate a new Java extension it means code changes and > re-compilations. > If developers know who they are, and possibly already call something to setup the development environment, then you could have *SYS level environment variable that sets up CLASSPATH for all-other-users, and developers could call some startup CL program that replaces that job's *JOB CLASSPATH envvar with the development version of the classpath. If the set-dev-envvar program wasn't called, the job would default to the all-other-users envvar. When you need to change the classpath, you have only two places to do it: the *SYS envvar and the program that sets the *JOB envvar. I would stay away from calling setClassPath from every program. It will become less and less reliable as more of your RPG programs use Java, for all three reasons you state.
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.