RE: ClassPath Woes - What the Heck is happening.

So based on what you said it sounds like I should have a CL program set the
classpath in the morning, and have that classpath include all possible Java
tools that my programs might make use of throughout the day. ??

It would be nice if the JVM would just check the classpath each time a call
is made vs. just at JVM startup.  But I am assuming that would make it even
slower than it already is. . .

Aaron Bartell  

-----Original Message-----
From: Barbara Morris [mailto:bmorris@xxxxxxxxxx]
Sent: Friday, September 12, 2003 6:15 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: ClassPath Woes - What the Heck is happening.


Buck wrote:
> Aaron wrote:
> > Whoa, wait a sec, do you mean that I am bringing down and starting the
JVM
> > each time I change or attempt to change the CLASSPATH?
> 
> I think it's more like 'When the JVM starts, it fetches the CLASSPATH and
> uses that one no matter what you set after that point.'
>   --buck
> 

Right.

Aaron also wrote:
>If I am another programmer in my shop, why should I have to care if Aaron
used
>Java behind the scenes for his RPGMail tool?  If it caused big problems
then
>yes they will need to care, but I still don't see the need if I can just
>monitor for a message if a CLASSPATH entry add attempt fails.  Am I missing
>something?

What if you use someone else's coolio tool that happens to use Java, and
then you try to run your RPGMail?  That first classpath wouldn't include
your directories - adding your directories to the CLASSPATH envvar
wouldn't make any difference because the JVM would have already been
started with the first classpath.

On V5R1, especially if you're doing development, you might not notice
this problem, because all the ILE compilers run in *NEW.  When the
compile ends, the *NEW actgrp ends, which causes the JVM to end.  When
you call your Java-using program again, you get a new JVM.  On V5R2,
this doesn't happen any more.