Classpath Environment Var replaced by a java OPTION!

[Thomas.Schneider.Wien]

Hello Chip & all,
   you have *NOT* to move any files at all.

I got the info (from Kermit Kiser), that there is a new option

-classpath <classpath>

in the Java Command (and probably also in JavaC and JavaW, but I still
have to try those).

I still have to try it, but sounds reasonable for me.

I will use it within my batch files ASAP.
Thomas.
=================================================================

Chip Davis schrieb:

> I'm not sure how I feel about Java deprecating the usage of the
> CLASSPATH variable.
>
> IMHO, it is not a good design if you have to move components of one
> application into the libraries of another component's installation in
> order to get them to work..
>
> Especially when those components are regularly (and frequently)
> updated.  As soon as you get your NetRexx application development
> environment up and running, SUN exhorts you to download the latest JDK.  
> I would be quite surprised (but I do not know) if the Java installation
> routine transfers all the JAR files in the old Java ext/ directory to
> the new one.
>
> So now I've got to (first) remember which NetRexx files need to be
> copied into which Java directories, and (second) move and test them.  
> And then deal with the JEdit files, and then the other external NetRexx
> packages, ... lather, rinse, repeat...  WAPITA.
>
> If all that were necessary is to update an environment variable or two,
> all the installer (for Java, NetRexx, or whatever) would have to do is
> update the appropriate entries in same, leaving the rest of the entries
> alone.  PooF!  Everything continues to work as before with the updated
> component.
>
> Requiring an invocation flag that explicitly provides the CLASSPATH is
> cumbersome (at best) and much too fine a granularity for normal usage.  
> By all means, provide a mechanism to override the current environment
> variables on invocation for testing/debugging purposes, but that should
> not be the preferred technique.
>
> -Chip-
>
> On 2/9/10 00:58 Bruce Skelly said:
>  
>> Kermit,
>>
>> I think that we are on the same page now.  The default classpath, does
>> include a lot of stuff, and yes the current directory is the last
>> place searched.  
>>
>> On Feb 8, 2010, at 12:27 PM, Kermit Kiser wrote:
>>
>>    
>>> Bruce ;
>>>
>>> My bad, I guess I failed to make it clear that the default classpaths
>>> include the period (current directory) and that your classpath is
>>> deleting it which is causing your problem. When you "unset" the
>>> CLASSPATH you are actually re-adding the current directory to the
>>> classpath.
>>>
>>> Your logic for not setting the CLASSPATH environment variable is
>>> exactly why the Java developers deprecated it and added the
>>> "-classpath" operand to all of the Java commands (java, javac, etc).
>>>
>>> -- Kermit
>>>
>>> Bruce Skelly wrote:
>>>      
>>>> See below
>>>> On Feb 8, 2010, at 11:50 AM, Kermit Kiser wrote:
>>>>
>>>>        
>>>>> Bruce ;
>>>>>
>>>>> Did you read my note? I am pretty sure that if you use the correct
>>>>> classpath with a period added for the current directory as I
>>>>> mentioned in item #3 that you will not need to "unset" the
>>>>> classpath to execute your program.
>>>>>          
>>>> Kermit, did you read my note.  I said that the only change I made
>>>> was to unset the CLASSPATH.  The default CLASSPATH must contain the
>>>> current directory or some other trickery.   Everything else that is
>>>> java on my machine seems to work just fine *without* a CLASSPATH.  I
>>>> choose just set the CLASSPATH for the duration of the NetRexxC.  My
>>>> concern is that by having a CLASSPATH in the environment, I may
>>>> cause other things to stop working.  I would then be on an endless
>>>> journey of tweaking my CLASSPATH so that things work.
>>>>        
>>>>> BTW: The CLASSPATH environment variable has been "deprecated" since
>>>>> Java 1.3 and is not recommended for various reasons. The correct
>>>>> way to call Java is now with a "-classpath" operand which specifies
>>>>> the path on the command line. That would give you a much simpler
>>>>> way to specify the classpath differently in the stages in your
>>>>> shell script.
>>>>>
>>>>> -- Kermit
>>>>>
>>>>>
>>>>> Bruce Skelly wrote:
>>>>>          
>>>>>> I don't know, we may be saying the same thing.
>>>>>>
>>>>>> I do know that even though both classes.jar and NetRexxC.jar are
>>>>>> in the default (implicit) CLASSPATH, that NetRexxC would fail
>>>>>> trying to create the '.java' file.  That is before the java
>>>>>> compiler is invoked.  In fact, using the -verbose argument to
>>>>>> java, showed me that many classes were loaded from both .jar files.
>>>>>>
>>>>>> If I gave it a CLASSPATH that contained just classes.jar, then it
>>>>>> would fail, looking for a NetRexx class.  If I gave it a CLASSPATH
>>>>>> that contained just NetRexxC.jar, it would fail looking for a java
>>>>>> class.  Specifying both classes.jar and NetRexxC.jar would produce
>>>>>> a .java file that could then be compiled into a .class file.
>>>>>>
>>>>>> At that point if I tried to execute the program, i.e. java
>>>>>> hello.class, it would fail.  If I then *unset* the CLASSPATH, I
>>>>>> could then type java hello.class and it would execute.
>>>>>>
>>>>>> I modified the distributed NetRexxC.sh file to do this on Darwin
>>>>>> systems  (Mac OS X), since it appears on my system, CLASSPATH is
>>>>>> only needed in the translation phase from .nrx to .java.
>>>>>> ...
>>>>>> # For Mac OS X with NetRexxC.jar installed in /Library/Java/Extensions
>>>>>> if [ "`uname`" = "Darwin" ]
>>>>>> then
>>>>>> CLASSPATH=/Library/Java/Extensions/NetRexxC.jar:/System/Library/Frameworks/JavaVM.framework/Classes/classes.jar
>>>>>> export CLASSPATH
>>>>>> fi
>>>>>> ...
>>>>>> # Again for Mac OS X;
>>>>>> if [ "`uname`" = "Darwin" ]
>>>>>> then
>>>>>>      unset CLASSPATH
>>>>>> fi
>>>>>> ...
>>>>>>
>>>>>> Bruce
>>>>>>
>>>>>> On Feb 8, 2010, at 10:49 AM, Kermit Kiser wrote:
>>>>>>
>>>>>>            
>>>>>>> Hi Bruce;
>>>>>>>
>>>>>>> 1) I don't know much about Mac stuff. (OK, zero ;-)
>>>>>>>
>>>>>>> 2) There are three stages to compiling and running a NetRexx
>>>>>>> program - first the NetRexx translator (NetRexxC) parses your
>>>>>>> code and converts it to Java code, second the translator calls
>>>>>>> the Java compiler (javac) to convert the Java code to "bytecode",
>>>>>>> third the Java virtual machine loads the bytecode, links it and
>>>>>>> executes it. At each stage a different program is handling your
>>>>>>> code and each one has to be able to find all the related classes.
>>>>>>> Sometimes they don't use the same procedure/path to find things
>>>>>>> but generally they will all obey the CLASSPATH environment
>>>>>>> variable. Each program has an internal default classpath but the
>>>>>>> environment variable will *override* the internal paths.
>>>>>>>
>>>>>>> 3) Solution: When you specify the CLASSPATH, you must include the
>>>>>>> code directory, usually with a "." (a period) or your program
>>>>>>> will not be found. Likewise you must include the Java classes and
>>>>>>> the NetRexx classes because you are overriding the default paths.
>>>>>>>
>>>>>>> 4) You can add NetRexxC.jar to the Java extensions directory so
>>>>>>> Java can find it in it's default path search but that may not
>>>>>>> help NetRexxC to find the classes it needs.
>>>>>>>
>>>>>>> 5) You may find that it is simpler to install the jEdit IDE with
>>>>>>> NetRexxDE and NetRexxScript plugins to compile and interpret
>>>>>>> NetRexx code, since the NetRexxC.jar file is automatically
>>>>>>> installed that way. (You will still need to download the NetRexx
>>>>>>> zip if you want the samples and docs.) If you wish to use the
>>>>>>> jEdit environment with the NetRexxScript plugin, be aware that
>>>>>>> jEdit uses custom classloaders to dynamically load things.
>>>>>>> Therefore if NetRexxC.jar is in the extensions directory for the
>>>>>>> Java VM that runs jEdit, NetRexxScript will encounter
>>>>>>> "invocation" errors when interpreting scripts due to the conflict
>>>>>>> between multiple classloader versions of the NetRexx classes.
>>>>>>>
>>>>>>> Hope some of this info helps,
>>>>>>>
>>>>>>> -- Kermit
>>>>>>>
>>>>>>>
>>>>>>> Bruce Skelly wrote:
>>>>>>>              
>>>>>>>> If I understand this correctly, after spending some time playing
>>>>>>>> with it, it isn't really that NetRexx doesn't execute unless you
>>>>>>>> specify the CLASSPATH.  What I *think* is happening is that the
>>>>>>>> NetRexx Compiler, in the course of generating java code needs to
>>>>>>>> look at the classes to determine their dependancies.  Kind of
>>>>>>>> like header files in C.  After the compile is complete, the
>>>>>>>> "headers" are no longer needed, and the compiled NetRexx (java)
>>>>>>>> program runs just fine without the CLASSPATH.  
>>>>>>>>
>>>>>>>> Please note in my messages, that NetRexxC was executing, but
>>>>>>>> issuing error messages stating that it couldn't find things
>>>>>>>> (classes).  Also, my compiled NetRexx program executes just fine
>>>>>>>> when I unset CLASSPATH, so it can find both the NetRexx runtime,
>>>>>>>> and the Java runtime.
>>>>>>>>
>>>>>>>>                
>>> _______________________________________________
>>> rexxla-members mailing list -- mailto:[hidden email]
>>> http://rice.safedataisp.net/mailman/listinfo/rexxla-members
>>>      
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> rexxla-members mailing list -- mailto:[hidden email]
>> http://rice.safedataisp.net/mailman/listinfo/rexxla-members
>>  
>>    
> _______________________________________________
> rexxla-members mailing list -- mailto:[hidden email]
> http://rice.safedataisp.net/mailman/listinfo/rexxla-members
>
>  

[Alan Sampson-2]

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7915 bytes
Desc: S/MIME Cryptographic Signature
Url : http://ns.hursley.ibm.com/pipermail/ibm-netrexx/attachments/20100209/67959c6f/smime-0001.bin

[Thomas.Schneider.Wien]

Thanks a lot, Alan, for this correction of my mail,  and clarification,
including the proper URL's.
Tom.
================================================================
Alan Sampson schrieb:

>
> The -classpath option has NOT replaced the CLASSPATH environment
> variable, nether is it NEW!  I think it was introduced sometime around
> Java 1.2 or 1.3.
>
> While we're discussing the -classpath option there's also the -cp,
> -Xbootclasspath, -bootclasspath and -jar options (and even
> -Djava.class.path=... -Dsun.boot.class.path=... for the terminally
> perverse) to name a few that control class loading.  They all play a
> part in deciding which (and which order) classes get loaded when a JVM
> starts.  There is no one correct way!
>
> Much of the information you're looking for is readily available in the
> Java documentation web site, currently
> http://java.sun.com/javase/reference/index.jsp although since Oracle's
> take-over of Sun who knows how long this domain will remain active.
>
> There's a reasonably good tutorial about loading Extension Classes
> here: http://java.sun.com/docs/books/tutorial/ext/basics/index.html 
> with some specifics of the class loading process here:
> http://java.sun.com/docs/books/tutorial/ext/basics/load.html.
>
> NetRexx is a Java application and thus it must obey the rules of the
> version of Java it's running under and that itself is a moving target.
>  Add to this any changes introduced by Sun/Oracle as they make
> improvements in Java to exploit new technologies there's no guarantee
> that the old ways will continue to work.
>
> My point is you must refer to the Java documentation to really
> understand how to run NetRexx.  Putting anything specific in the
> NetRexx documentation is unlikely to be correct for every existing
> version of the JDK and will become obsolete as soon as it's written.
>
> Alan.
>
>
> [hidden email] wrote on 02/09/2010 05:47:50 AM:
>
> > [image removed]
> >
> > [Ibm-netrexx] Classpath Environment Var replaced by a java OPTION!
> >
> > Thomas Schneider
> >
> > to:
> >
> > RexxLA Members mailing list
> >
> > 02/09/2010 06:10 AM
> >
> > Sent by:
> >
> > [hidden email]
> >
> > Cc:
> >
> > IBM Netrexx
> >
> > Please respond to IBM Netrexx
> >
> > Hello Chip & all,
> >    you have *NOT* to move any files at all.
> >
> > I got the info (from Kermit Kiser), that there is a new option
> >
> > -classpath <classpath>
> >
> > in the Java Command (and probably also in JavaC and JavaW, but I still
> > have to try those).
> >
> > I still have to try it, but sounds reasonable for me.
> >
> > I will use it within my batch files ASAP.
> > Thomas.
> > =================================================================
> >
> > Chip Davis schrieb:
> > > I'm not sure how I feel about Java deprecating the usage of the
> > > CLASSPATH variable.
> > >
> > > IMHO, it is not a good design if you have to move components of one
> > > application into the libraries of another component's installation in
> > > order to get them to work..
> > >
> > > Especially when those components are regularly (and frequently)
> > > updated.  As soon as you get your NetRexx application development
> > > environment up and running, SUN exhorts you to download the latest
> JDK.  
> > > I would be quite surprised (but I do not know) if the Java
> installation
> > > routine transfers all the JAR files in the old Java ext/ directory to
> > > the new one.
> > >
> > > So now I've got to (first) remember which NetRexx files need to be
> > > copied into which Java directories, and (second) move and test them.  
> > > And then deal with the JEdit files, and then the other external
> NetRexx
> > > packages, ... lather, rinse, repeat...  WAPITA.
> > >
> > > If all that were necessary is to update an environment variable or
> two,
> > > all the installer (for Java, NetRexx, or whatever) would have to
> do is
> > > update the appropriate entries in same, leaving the rest of the
> entries
> > > alone.  PooF!  Everything continues to work as before with the
> updated
> > > component.
> > >
> > > Requiring an invocation flag that explicitly provides the
> CLASSPATH is
> > > cumbersome (at best) and much too fine a granularity for normal
> usage.  
> > > By all means, provide a mechanism to override the current environment
> > > variables on invocation for testing/debugging purposes, but that
> should
> > > not be the preferred technique.
> > >
> > > -Chip-
> > >
> > > On 2/9/10 00:58 Bruce Skelly said:
> > >  
> > >> Kermit,
> > >>
> > >> I think that we are on the same page now.  The default classpath,
> does
> > >> include a lot of stuff, and yes the current directory is the last
> > >> place searched.  
> > >>
> > >> On Feb 8, 2010, at 12:27 PM, Kermit Kiser wrote:
> > >>
> > >>    
> > >>> Bruce ;
> > >>>
> > >>> My bad, I guess I failed to make it clear that the default
> classpaths
> > >>> include the period (current directory) and that your classpath is
> > >>> deleting it which is causing your problem. When you "unset" the
> > >>> CLASSPATH you are actually re-adding the current directory to the
> > >>> classpath.
> > >>>
> > >>> Your logic for not setting the CLASSPATH environment variable is
> > >>> exactly why the Java developers deprecated it and added the
> > >>> "-classpath" operand to all of the Java commands (java, javac, etc).
> > >>>
> > >>> -- Kermit
> > >>>
> > >>> Bruce Skelly wrote:
> > >>>      
> > >>>> See below
> > >>>> On Feb 8, 2010, at 11:50 AM, Kermit Kiser wrote:
> > >>>>
> > >>>>        
> > >>>>> Bruce ;
> > >>>>>
> > >>>>> Did you read my note? I am pretty sure that if you use the
> correct
> > >>>>> classpath with a period added for the current directory as I
> > >>>>> mentioned in item #3 that you will not need to "unset" the
> > >>>>> classpath to execute your program.
> > >>>>>          
> > >>>> Kermit, did you read my note.  I said that the only change I made
> > >>>> was to unset the CLASSPATH.  The default CLASSPATH must contain
> the
> > >>>> current directory or some other trickery.   Everything else
> that is
> > >>>> java on my machine seems to work just fine *without* a
> CLASSPATH.  I
> > >>>> choose just set the CLASSPATH for the duration of the NetRexxC.
>  My
> > >>>> concern is that by having a CLASSPATH in the environment, I may
> > >>>> cause other things to stop working.  I would then be on an endless
> > >>>> journey of tweaking my CLASSPATH so that things work.
> > >>>>        
> > >>>>> BTW: The CLASSPATH environment variable has been "deprecated"
> since
> > >>>>> Java 1.3 and is not recommended for various reasons. The correct
> > >>>>> way to call Java is now with a "-classpath" operand which
> specifies
> > >>>>> the path on the command line. That would give you a much simpler
> > >>>>> way to specify the classpath differently in the stages in your
> > >>>>> shell script.
> > >>>>>
> > >>>>> -- Kermit
> > >>>>>
> > >>>>>
> > >>>>> Bruce Skelly wrote:
> > >>>>>          
> > >>>>>> I don't know, we may be saying the same thing.
> > >>>>>>
> > >>>>>> I do know that even though both classes.jar and NetRexxC.jar are
> > >>>>>> in the default (implicit) CLASSPATH, that NetRexxC would fail
> > >>>>>> trying to create the '.java' file.  That is before the java
> > >>>>>> compiler is invoked.  In fact, using the -verbose argument to
> > >>>>>> java, showed me that many classes were loaded from both .jar
> files.
> > >>>>>>
> > >>>>>> If I gave it a CLASSPATH that contained just classes.jar,
> then it
> > >>>>>> would fail, looking for a NetRexx class.  If I gave it a
> CLASSPATH
> > >>>>>> that contained just NetRexxC.jar, it would fail looking for a
> java
> > >>>>>> class.  Specifying both classes.jar and NetRexxC.jar would
> produce
> > >>>>>> a .java file that could then be compiled into a .class file.
> > >>>>>>
> > >>>>>> At that point if I tried to execute the program, i.e. java
> > >>>>>> hello.class, it would fail.  If I then *unset* the CLASSPATH, I
> > >>>>>> could then type java hello.class and it would execute.
> > >>>>>>
> > >>>>>> I modified the distributed NetRexxC.sh file to do this on Darwin
> > >>>>>> systems  (Mac OS X), since it appears on my system, CLASSPATH is
> > >>>>>> only needed in the translation phase from .nrx to .java.
> > >>>>>> ...
> > >>>>>> # For Mac OS X with NetRexxC.jar installed in
> /Library/Java/Extensions
> > >>>>>> if [ "`uname`" = "Darwin" ]
> > >>>>>> then
> > >>>>>> CLASSPATH=/Library/Java/Extensions/NetRexxC.jar:/System/
> > Library/Frameworks/JavaVM.framework/Classes/classes.jar
> > >>>>>> export CLASSPATH
> > >>>>>> fi
> > >>>>>> ...
> > >>>>>> # Again for Mac OS X;
> > >>>>>> if [ "`uname`" = "Darwin" ]
> > >>>>>> then
> > >>>>>>      unset CLASSPATH
> > >>>>>> fi
> > >>>>>> ...
> > >>>>>>
> > >>>>>> Bruce
> > >>>>>>
> > >>>>>> On Feb 8, 2010, at 10:49 AM, Kermit Kiser wrote:
> > >>>>>>
> > >>>>>>            
> > >>>>>>> Hi Bruce;
> > >>>>>>>
> > >>>>>>> 1) I don't know much about Mac stuff. (OK, zero ;-)
> > >>>>>>>
> > >>>>>>> 2) There are three stages to compiling and running a NetRexx
> > >>>>>>> program - first the NetRexx translator (NetRexxC) parses your
> > >>>>>>> code and converts it to Java code, second the translator calls
> > >>>>>>> the Java compiler (javac) to convert the Java code to
> "bytecode",
> > >>>>>>> third the Java virtual machine loads the bytecode, links it and
> > >>>>>>> executes it. At each stage a different program is handling your
> > >>>>>>> code and each one has to be able to find all the related
> classes.
> > >>>>>>> Sometimes they don't use the same procedure/path to find things
> > >>>>>>> but generally they will all obey the CLASSPATH environment
> > >>>>>>> variable. Each program has an internal default classpath but
> the
> > >>>>>>> environment variable will *override* the internal paths.
> > >>>>>>>
> > >>>>>>> 3) Solution: When you specify the CLASSPATH, you must
> include the
> > >>>>>>> code directory, usually with a "." (a period) or your program
> > >>>>>>> will not be found. Likewise you must include the Java
> classes and
> > >>>>>>> the NetRexx classes because you are overriding the default
> paths.
> > >>>>>>>
> > >>>>>>> 4) You can add NetRexxC.jar to the Java extensions directory so
> > >>>>>>> Java can find it in it's default path search but that may not
> > >>>>>>> help NetRexxC to find the classes it needs.
> > >>>>>>>
> > >>>>>>> 5) You may find that it is simpler to install the jEdit IDE
> with
> > >>>>>>> NetRexxDE and NetRexxScript plugins to compile and interpret
> > >>>>>>> NetRexx code, since the NetRexxC.jar file is automatically
> > >>>>>>> installed that way. (You will still need to download the
> NetRexx
> > >>>>>>> zip if you want the samples and docs.) If you wish to use the
> > >>>>>>> jEdit environment with the NetRexxScript plugin, be aware that
> > >>>>>>> jEdit uses custom classloaders to dynamically load things.
> > >>>>>>> Therefore if NetRexxC.jar is in the extensions directory for
> the
> > >>>>>>> Java VM that runs jEdit, NetRexxScript will encounter
> > >>>>>>> "invocation" errors when interpreting scripts due to the
> conflict
> > >>>>>>> between multiple classloader versions of the NetRexx classes.
> > >>>>>>>
> > >>>>>>> Hope some of this info helps,
> > >>>>>>>
> > >>>>>>> -- Kermit
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> Bruce Skelly wrote:
> > >>>>>>>              
> > >>>>>>>> If I understand this correctly, after spending some time
> playing
> > >>>>>>>> with it, it isn't really that NetRexx doesn't execute
> unless you
> > >>>>>>>> specify the CLASSPATH.  What I *think* is happening is that
> the
> > >>>>>>>> NetRexx Compiler, in the course of generating java code
> needs to
> > >>>>>>>> look at the classes to determine their dependancies.  Kind of
> > >>>>>>>> like header files in C.  After the compile is complete, the
> > >>>>>>>> "headers" are no longer needed, and the compiled NetRexx
> (java)
> > >>>>>>>> program runs just fine without the CLASSPATH.  
> > >>>>>>>>
> > >>>>>>>> Please note in my messages, that NetRexxC was executing, but
> > >>>>>>>> issuing error messages stating that it couldn't find things
> > >>>>>>>> (classes).  Also, my compiled NetRexx program executes just
> fine
> > >>>>>>>> when I unset CLASSPATH, so it can find both the NetRexx
> runtime,
> > >>>>>>>> and the Java runtime.
> > >>>>>>>>
> > >>>>>>>>                
> > >>> _______________________________________________
> > >>> rexxla-members mailing list -- mailto:[hidden email]
> > >>> http://rice.safedataisp.net/mailman/listinfo/rexxla-members
> > >>>      
> > >>
> ------------------------------------------------------------------------
> > >>
> > >> _______________________________________________
> > >> rexxla-members mailing list -- mailto:[hidden email]
> > >> http://rice.safedataisp.net/mailman/listinfo/rexxla-members
> > >>  
> > >>    
> > > _______________________________________________
> > > rexxla-members mailing list -- mailto:[hidden email]
> > > http://rice.safedataisp.net/mailman/listinfo/rexxla-members
> > >
> > >  
> >
> > _______________________________________________
> > Ibm-netrexx mailing list
> > [hidden email]
> >
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
>
>  

[rvjansen]

Hi Alan,

I agree with this - it is a matter of requirements and taste how we decide to find our classes. In this respect we are bound by the rules that the environment imposes on us. These are not as human centric as NetRexx itself.

On the other hand, it must not be too hard to install NetRexx for the first time on your platform.

My current thoughts on this are roughly these

- the translator itself needs a small module that 'knows' where to find some java runtime components on platforms where those are fixed - but that cannot supercede choices made by the more adept platform users, so it must be activated on the known exceptions  - cannot load java.lang.Object, or does not find the compiler from the tools archive (if packaged like this by the specific JVM implementation).

- we must not repeat the official Java documentation in the generic NetRexx docs, except in documents tailored to specific platforms. I spent most of three hours to get it running on z/Linux before being helped by Bengt Heijnesson from IBM GTS Sweden. I foresee platform install documents for most platform/JVM combinations.

- BSF4Rexx for ooRexx has an optional installer program that tries to find out where things are located; I am sure that Rony can help us to make an analogous NetRexx version


btw - I get certificate warnings on your emails - do I need to import a specific CA certificate?

best regards,

Ren? Jansen.

On 9 feb 2010, at 19:26, Alan Sampson wrote:

> The -classpath option has NOT replaced the CLASSPATH environment variable, nether is it NEW!  I think it was introduced sometime around Java 1.2 or 1.3.
>
> While we're discussing the -classpath option there's also the -cp, -Xbootclasspath, -bootclasspath and -jar options (and even -Djava.class.path=... -Dsun.boot.class.path=... for the terminally perverse) to name a few that control class loading.  They all play a part in deciding which (and which order) classes get loaded when a JVM starts.  There is no one correct way!
>
> Much of the information you're looking for is readily available in the Java documentation web site, currently http://java.sun.com/javase/reference/index.jsp although since Oracle's take-over of Sun who knows how long this domain will remain active.
>
> There's a reasonably good tutorial about loading Extension Classes here: http://java.sun.com/docs/books/tutorial/ext/basics/index.html with some specifics of the class loading process here: http://java.sun.com/docs/books/tutorial/ext/basics/load.html.
>
> NetRexx is a Java application and thus it must obey the rules of the version of Java it's running under and that itself is a moving target.  Add to this any changes introduced by Sun/Oracle as they make improvements in Java to exploit new technologies there's no guarantee that the old ways will continue to work.
>
> My point is you must refer to the Java documentation to really understand how to run NetRexx.  Putting anything specific in the NetRexx documentation is unlikely to be correct for every existing version of the JDK and will become obsolete as soon as it's written.
>
> Alan.
>
>
> [hidden email] wrote on 02/09/2010 05:47:50 AM:
>
> > [image removed]
> >
> > [Ibm-netrexx] Classpath Environment Var replaced by a java OPTION!
> >
> > Thomas Schneider
> >
> > to:
> >
> > RexxLA Members mailing list
> >
> > 02/09/2010 06:10 AM
> >
> > Sent by:
> >
> > [hidden email]
> >
> > Cc:
> >
> > IBM Netrexx
> >
> > Please respond to IBM Netrexx
> >
> > Hello Chip & all,
> >    you have *NOT* to move any files at all.
> >
> > I got the info (from Kermit Kiser), that there is a new option
> >
> > -classpath <classpath>
> >
> > in the Java Command (and probably also in JavaC and JavaW, but I still
> > have to try those).
> >
> > I still have to try it, but sounds reasonable for me.
> >
> > I will use it within my batch files ASAP.
> > Thomas.
> > =================================================================
> >
> > Chip Davis schrieb:
> > > I'm not sure how I feel about Java deprecating the usage of the
> > > CLASSPATH variable.
> > >
> > > IMHO, it is not a good design if you have to move components of one
> > > application into the libraries of another component's installation in
> > > order to get them to work..
> > >
> > > Especially when those components are regularly (and frequently)
> > > updated.  As soon as you get your NetRexx application development
> > > environment up and running, SUN exhorts you to download the latest JDK.  
> > > I would be quite surprised (but I do not know) if the Java installation
> > > routine transfers all the JAR files in the old Java ext/ directory to
> > > the new one.
> > >
> > > So now I've got to (first) remember which NetRexx files need to be
> > > copied into which Java directories, and (second) move and test them.  
> > > And then deal with the JEdit files, and then the other external NetRexx
> > > packages, ... lather, rinse, repeat...  WAPITA.
> > >
> > > If all that were necessary is to update an environment variable or two,
> > > all the installer (for Java, NetRexx, or whatever) would have to do is
> > > update the appropriate entries in same, leaving the rest of the entries
> > > alone.  PooF!  Everything continues to work as before with the updated
> > > component.
> > >
> > > Requiring an invocation flag that explicitly provides the CLASSPATH is
> > > cumbersome (at best) and much too fine a granularity for normal usage.  
> > > By all means, provide a mechanism to override the current environment
> > > variables on invocation for testing/debugging purposes, but that should
> > > not be the preferred technique.
> > >
> > > -Chip-
> > >
> > > On 2/9/10 00:58 Bruce Skelly said:
> > >  
> > >> Kermit,
> > >>
> > >> I think that we are on the same page now.  The default classpath, does
> > >> include a lot of stuff, and yes the current directory is the last
> > >> place searched.  
> > >>
> > >> On Feb 8, 2010, at 12:27 PM, Kermit Kiser wrote:
> > >>
> > >>    
> > >>> Bruce ;
> > >>>
> > >>> My bad, I guess I failed to make it clear that the default classpaths
> > >>> include the period (current directory) and that your classpath is
> > >>> deleting it which is causing your problem. When you "unset" the
> > >>> CLASSPATH you are actually re-adding the current directory to the
> > >>> classpath.
> > >>>
> > >>> Your logic for not setting the CLASSPATH environment variable is
> > >>> exactly why the Java developers deprecated it and added the
> > >>> "-classpath" operand to all of the Java commands (java, javac, etc).
> > >>>
> > >>> -- Kermit
> > >>>
> > >>> Bruce Skelly wrote:
> > >>>      
> > >>>> See below
> > >>>> On Feb 8, 2010, at 11:50 AM, Kermit Kiser wrote:
> > >>>>
> > >>>>        
> > >>>>> Bruce ;
> > >>>>>
> > >>>>> Did you read my note? I am pretty sure that if you use the correct
> > >>>>> classpath with a period added for the current directory as I
> > >>>>> mentioned in item #3 that you will not need to "unset" the
> > >>>>> classpath to execute your program.
> > >>>>>          
> > >>>> Kermit, did you read my note.  I said that the only change I made
> > >>>> was to unset the CLASSPATH.  The default CLASSPATH must contain the
> > >>>> current directory or some other trickery.   Everything else that is
> > >>>> java on my machine seems to work just fine *without* a CLASSPATH.  I
> > >>>> choose just set the CLASSPATH for the duration of the NetRexxC.  My
> > >>>> concern is that by having a CLASSPATH in the environment, I may
> > >>>> cause other things to stop working.  I would then be on an endless
> > >>>> journey of tweaking my CLASSPATH so that things work.
> > >>>>        
> > >>>>> BTW: The CLASSPATH environment variable has been "deprecated" since
> > >>>>> Java 1.3 and is not recommended for various reasons. The correct
> > >>>>> way to call Java is now with a "-classpath" operand which specifies
> > >>>>> the path on the command line. That would give you a much simpler
> > >>>>> way to specify the classpath differently in the stages in your
> > >>>>> shell script.
> > >>>>>
> > >>>>> -- Kermit
> > >>>>>
> > >>>>>
> > >>>>> Bruce Skelly wrote:
> > >>>>>          
> > >>>>>> I don't know, we may be saying the same thing.
> > >>>>>>
> > >>>>>> I do know that even though both classes.jar and NetRexxC.jar are
> > >>>>>> in the default (implicit) CLASSPATH, that NetRexxC would fail
> > >>>>>> trying to create the '.java' file.  That is before the java
> > >>>>>> compiler is invoked.  In fact, using the -verbose argument to
> > >>>>>> java, showed me that many classes were loaded from both .jar files.
> > >>>>>>
> > >>>>>> If I gave it a CLASSPATH that contained just classes.jar, then it
> > >>>>>> would fail, looking for a NetRexx class.  If I gave it a CLASSPATH
> > >>>>>> that contained just NetRexxC.jar, it would fail looking for a java
> > >>>>>> class.  Specifying both classes.jar and NetRexxC.jar would produce
> > >>>>>> a .java file that could then be compiled into a .class file.
> > >>>>>>
> > >>>>>> At that point if I tried to execute the program, i.e. java
> > >>>>>> hello.class, it would fail.  If I then *unset* the CLASSPATH, I
> > >>>>>> could then type java hello.class and it would execute.
> > >>>>>>
> > >>>>>> I modified the distributed NetRexxC.sh file to do this on Darwin
> > >>>>>> systems  (Mac OS X), since it appears on my system, CLASSPATH is
> > >>>>>> only needed in the translation phase from .nrx to .java.
> > >>>>>> ...
> > >>>>>> # For Mac OS X with NetRexxC.jar installed in /Library/Java/Extensions
> > >>>>>> if [ "`uname`" = "Darwin" ]
> > >>>>>> then
> > >>>>>> CLASSPATH=/Library/Java/Extensions/NetRexxC.jar:/System/
> > Library/Frameworks/JavaVM.framework/Classes/classes.jar
> > >>>>>> export CLASSPATH
> > >>>>>> fi
> > >>>>>> ...
> > >>>>>> # Again for Mac OS X;
> > >>>>>> if [ "`uname`" = "Darwin" ]
> > >>>>>> then
> > >>>>>>      unset CLASSPATH
> > >>>>>> fi
> > >>>>>> ...
> > >>>>>>
> > >>>>>> Bruce
> > >>>>>>
> > >>>>>> On Feb 8, 2010, at 10:49 AM, Kermit Kiser wrote:
> > >>>>>>
> > >>>>>>            
> > >>>>>>> Hi Bruce;
> > >>>>>>>
> > >>>>>>> 1) I don't know much about Mac stuff. (OK, zero ;-)
> > >>>>>>>
> > >>>>>>> 2) There are three stages to compiling and running a NetRexx
> > >>>>>>> program - first the NetRexx translator (NetRexxC) parses your
> > >>>>>>> code and converts it to Java code, second the translator calls
> > >>>>>>> the Java compiler (javac) to convert the Java code to "bytecode",
> > >>>>>>> third the Java virtual machine loads the bytecode, links it and
> > >>>>>>> executes it. At each stage a different program is handling your
> > >>>>>>> code and each one has to be able to find all the related classes.
> > >>>>>>> Sometimes they don't use the same procedure/path to find things
> > >>>>>>> but generally they will all obey the CLASSPATH environment
> > >>>>>>> variable. Each program has an internal default classpath but the
> > >>>>>>> environment variable will *override* the internal paths.
> > >>>>>>>
> > >>>>>>> 3) Solution: When you specify the CLASSPATH, you must include the
> > >>>>>>> code directory, usually with a "." (a period) or your program
> > >>>>>>> will not be found. Likewise you must include the Java classes and
> > >>>>>>> the NetRexx classes because you are overriding the default paths.
> > >>>>>>>
> > >>>>>>> 4) You can add NetRexxC.jar to the Java extensions directory so
> > >>>>>>> Java can find it in it's default path search but that may not
> > >>>>>>> help NetRexxC to find the classes it needs.
> > >>>>>>>
> > >>>>>>> 5) You may find that it is simpler to install the jEdit IDE with
> > >>>>>>> NetRexxDE and NetRexxScript plugins to compile and interpret
> > >>>>>>> NetRexx code, since the NetRexxC.jar file is automatically
> > >>>>>>> installed that way. (You will still need to download the NetRexx
> > >>>>>>> zip if you want the samples and docs.) If you wish to use the
> > >>>>>>> jEdit environment with the NetRexxScript plugin, be aware that
> > >>>>>>> jEdit uses custom classloaders to dynamically load things.
> > >>>>>>> Therefore if NetRexxC.jar is in the extensions directory for the
> > >>>>>>> Java VM that runs jEdit, NetRexxScript will encounter
> > >>>>>>> "invocation" errors when interpreting scripts due to the conflict
> > >>>>>>> between multiple classloader versions of the NetRexx classes.
> > >>>>>>>
> > >>>>>>> Hope some of this info helps,
> > >>>>>>>
> > >>>>>>> -- Kermit
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> Bruce Skelly wrote:
> > >>>>>>>              
> > >>>>>>>> If I understand this correctly, after spending some time playing
> > >>>>>>>> with it, it isn't really that NetRexx doesn't execute unless you
> > >>>>>>>> specify the CLASSPATH.  What I *think* is happening is that the
> > >>>>>>>> NetRexx Compiler, in the course of generating java code needs to
> > >>>>>>>> look at the classes to determine their dependancies.  Kind of
> > >>>>>>>> like header files in C.  After the compile is complete, the
> > >>>>>>>> "headers" are no longer needed, and the compiled NetRexx (java)
> > >>>>>>>> program runs just fine without the CLASSPATH.  
> > >>>>>>>>
> > >>>>>>>> Please note in my messages, that NetRexxC was executing, but
> > >>>>>>>> issuing error messages stating that it couldn't find things
> > >>>>>>>> (classes).  Also, my compiled NetRexx program executes just fine
> > >>>>>>>> when I unset CLASSPATH, so it can find both the NetRexx runtime,
> > >>>>>>>> and the Java runtime.
> > >>>>>>>>
> > >>>>>>>>                
> > >>> _______________________________________________
> > >>> rexxla-members mailing list -- mailto:[hidden email]
> > >>> http://rice.safedataisp.net/mailman/listinfo/rexxla-members
> > >>>      
> > >> ------------------------------------------------------------------------
> > >>
> > >> _______________________________________________
> > >> rexxla-members mailing list -- mailto:[hidden email]
> > >> http://rice.safedataisp.net/mailman/listinfo/rexxla-members
> > >>  
> > >>    
> > > _______________________________________________
> > > rexxla-members mailing list -- mailto:[hidden email]
> > > http://rice.safedataisp.net/mailman/listinfo/rexxla-members
> > >
> > >  
> >
> > _______________________________________________
> > Ibm-netrexx mailing list
> > [hidden email]
> >
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ns.hursley.ibm.com/pipermail/ibm-netrexx/attachments/20100210/73101eed/attachment-0001.html

[Bruce Skelly]

Alan,

When I execute the compiler NetRexxC with the verbose option, I can  
see that the classes.jar file is opened, and the NetRexxC.jar file is  
opened and classes are loaded from each of them.

If I don't have a CLASSPATH defined in the environment, or a -
classpath option set on the command line, the translator loops,  
looking for what is in classes.jar and NetRexxC.jar, until it runs out  
of memory even though it has them open and has loaded classes from them.

The fact that it loops and doesn't abend/terminate means that the java  
runtime is finding all of the classes it needs to execute the program.

Perhaps this internal classpath that java is using isn't exposed to  
the program it is running, or if it is exposed, perhaps not in the way  
that the program logic expects.

In either case, unless I specify both classes.jar and NetRexxC.jar  in  
the CLASSPATH environmental variable, or in the -classpath command  
line option, I don't get the compiler to work.

I think the issue is more of a NetRexxC internals issue than it is a  
java issue.  I think that the compiler is trying to read the classes,  
not load them.  This is a subtile difference, I admit, but can cause  
java to use different internal logic.

Bruce

On Feb 9, 2010, at 10:26 AM, Alan Sampson wrote:

> The -classpath option has NOT replaced the CLASSPATH environment  
> variable, nether is it NEW!  I think it was introduced sometime  
> around Java 1.2 or 1.3.
>
> While we're discussing the -classpath option there's also the -cp, -
> Xbootclasspath, -bootclasspath and -jar options (and even -
> Djava.class.path=... -Dsun.boot.class.path=... for the terminally  
> perverse) to name a few that control class loading.  They all play a  
> part in deciding which (and which order) classes get loaded when a  
> JVM starts.  There is no one correct way!
>
> Much of the information you're looking for is readily available in  
> the Java documentation web site, currently http://java.sun.com/javase/reference/index.jsp 
>  although since Oracle's take-over of Sun who knows how long this  
> domain will remain active.
>
> There's a reasonably good tutorial about loading Extension Classes  
> here: http://java.sun.com/docs/books/tutorial/ext/basics/index.html 
> with some specifics of the class loading process here: http://java.sun.com/docs/books/tutorial/ext/basics/load.html 
> .
>
> NetRexx is a Java application and thus it must obey the rules of the  
> version of Java it's running under and that itself is a moving  
> target.  Add to this any changes introduced by Sun/Oracle as they  
> make improvements in Java to exploit new technologies there's no  
> guarantee that the old ways will continue to work.
>
> My point is you must refer to the Java documentation to really  
> understand how to run NetRexx.  Putting anything specific in the  
> NetRexx documentation is unlikely to be correct for every existing  
> version of the JDK and will become obsolete as soon as it's written.
>
> Alan.
>
>
> [hidden email] wrote on 02/09/2010 05:47:50 AM:
>
> > [image removed]
> >
> > [Ibm-netrexx] Classpath Environment Var replaced by a java OPTION!
> >
> > Thomas Schneider
> >
> > to:
> >
> > RexxLA Members mailing list
> >
> > 02/09/2010 06:10 AM
> >
> > Sent by:
> >
> > [hidden email]
> >
> > Cc:
> >
> > IBM Netrexx
> >
> > Please respond to IBM Netrexx
> >
> > Hello Chip & all,
> >    you have *NOT* to move any files at all.
> >
> > I got the info (from Kermit Kiser), that there is a new option
> >
> > -classpath <classpath>
> >
> > in the Java Command (and probably also in JavaC and JavaW, but I  
> still
> > have to try those).
> >
> > I still have to try it, but sounds reasonable for me.
> >
> > I will use it within my batch files ASAP.
> > Thomas.
> > =================================================================
> >
> > Chip Davis schrieb:
> > > I'm not sure how I feel about Java deprecating the usage of the
> > > CLASSPATH variable.
> > >
> > > IMHO, it is not a good design if you have to move components of  
> one
> > > application into the libraries of another component's  
> installation in
> > > order to get them to work..
> > >
> > > Especially when those components are regularly (and frequently)
> > > updated.  As soon as you get your NetRexx application development
> > > environment up and running, SUN exhorts you to download the  
> latest JDK.
> > > I would be quite surprised (but I do not know) if the Java  
> installation
> > > routine transfers all the JAR files in the old Java ext/  
> directory to
> > > the new one.
> > >
> > > So now I've got to (first) remember which NetRexx files need to be
> > > copied into which Java directories, and (second) move and test  
> them.
> > > And then deal with the JEdit files, and then the other external  
> NetRexx
> > > packages, ... lather, rinse, repeat...  WAPITA.
> > >
> > > If all that were necessary is to update an environment variable  
> or two,
> > > all the installer (for Java, NetRexx, or whatever) would have to  
> do is
> > > update the appropriate entries in same, leaving the rest of the  
> entries
> > > alone.  PooF!  Everything continues to work as before with the  
> updated
> > > component.
> > >
> > > Requiring an invocation flag that explicitly provides the  
> CLASSPATH is
> > > cumbersome (at best) and much too fine a granularity for normal  
> usage.
> > > By all means, provide a mechanism to override the current  
> environment
> > > variables on invocation for testing/debugging purposes, but that  
> should
> > > not be the preferred technique.
> > >
> > > -Chip-
> > >
> > > On 2/9/10 00:58 Bruce Skelly said:
> > >
> > >> Kermit,
> > >>
> > >> I think that we are on the same page now.  The default  
> classpath, does
> > >> include a lot of stuff, and yes the current directory is the last
> > >> place searched.
> > >>
> > >> On Feb 8, 2010, at 12:27 PM, Kermit Kiser wrote:
> > >>
> > >>
> > >>> Bruce ;
> > >>>
> > >>> My bad, I guess I failed to make it clear that the default  
> classpaths
> > >>> include the period (current directory) and that your classpath  
> is
> > >>> deleting it which is causing your problem. When you "unset" the
> > >>> CLASSPATH you are actually re-adding the current directory to  
> the
> > >>> classpath.
> > >>>
> > >>> Your logic for not setting the CLASSPATH environment variable is
> > >>> exactly why the Java developers deprecated it and added the
> > >>> "-classpath" operand to all of the Java commands (java, javac,  
> etc).
> > >>>
> > >>> -- Kermit
> > >>>
> > >>> Bruce Skelly wrote:
> > >>>
> > >>>> See below
> > >>>> On Feb 8, 2010, at 11:50 AM, Kermit Kiser wrote:
> > >>>>
> > >>>>
> > >>>>> Bruce ;
> > >>>>>
> > >>>>> Did you read my note? I am pretty sure that if you use the  
> correct
> > >>>>> classpath with a period added for the current directory as I
> > >>>>> mentioned in item #3 that you will not need to "unset" the
> > >>>>> classpath to execute your program.
> > >>>>>
> > >>>> Kermit, did you read my note.  I said that the only change I  
> made
> > >>>> was to unset the CLASSPATH.  The default CLASSPATH must  
> contain the
> > >>>> current directory or some other trickery.   Everything else  
> that is
> > >>>> java on my machine seems to work just fine *without* a  
> CLASSPATH.  I
> > >>>> choose just set the CLASSPATH for the duration of the  
> NetRexxC.  My
> > >>>> concern is that by having a CLASSPATH in the environment, I may
> > >>>> cause other things to stop working.  I would then be on an  
> endless
> > >>>> journey of tweaking my CLASSPATH so that things work.
> > >>>>
> > >>>>> BTW: The CLASSPATH environment variable has been  
> "deprecated" since
> > >>>>> Java 1.3 and is not recommended for various reasons. The  
> correct
> > >>>>> way to call Java is now with a "-classpath" operand which  
> specifies
> > >>>>> the path on the command line. That would give you a much  
> simpler
> > >>>>> way to specify the classpath differently in the stages in your
> > >>>>> shell script.
> > >>>>>
> > >>>>> -- Kermit
> > >>>>>
> > >>>>>
> > >>>>> Bruce Skelly wrote:
> > >>>>>
> > >>>>>> I don't know, we may be saying the same thing.
> > >>>>>>
> > >>>>>> I do know that even though both classes.jar and  
> NetRexxC.jar are
> > >>>>>> in the default (implicit) CLASSPATH, that NetRexxC would fail
> > >>>>>> trying to create the '.java' file.  That is before the java
> > >>>>>> compiler is invoked.  In fact, using the -verbose argument to
> > >>>>>> java, showed me that many classes were loaded from  
> both .jar files.
> > >>>>>>
> > >>>>>> If I gave it a CLASSPATH that contained just classes.jar,  
> then it
> > >>>>>> would fail, looking for a NetRexx class.  If I gave it a  
> CLASSPATH
> > >>>>>> that contained just NetRexxC.jar, it would fail looking for  
> a java
> > >>>>>> class.  Specifying both classes.jar and NetRexxC.jar would  
> produce
> > >>>>>> a .java file that could then be compiled into a .class file.
> > >>>>>>
> > >>>>>> At that point if I tried to execute the program, i.e. java
> > >>>>>> hello.class, it would fail.  If I then *unset* the  
> CLASSPATH, I
> > >>>>>> could then type java hello.class and it would execute.
> > >>>>>>
> > >>>>>> I modified the distributed NetRexxC.sh file to do this on  
> Darwin
> > >>>>>> systems  (Mac OS X), since it appears on my system,  
> CLASSPATH is
> > >>>>>> only needed in the translation phase from .nrx to .java.
> > >>>>>> ...
> > >>>>>> # For Mac OS X with NetRexxC.jar installed in /Library/Java/
> Extensions
> > >>>>>> if [ "`uname`" = "Darwin" ]
> > >>>>>> then
> > >>>>>> CLASSPATH=/Library/Java/Extensions/NetRexxC.jar:/System/
> > Library/Frameworks/JavaVM.framework/Classes/classes.jar
> > >>>>>> export CLASSPATH
> > >>>>>> fi
> > >>>>>> ...
> > >>>>>> # Again for Mac OS X;
> > >>>>>> if [ "`uname`" = "Darwin" ]
> > >>>>>> then
> > >>>>>>      unset CLASSPATH
> > >>>>>> fi
> > >>>>>> ...
> > >>>>>>
> > >>>>>> Bruce
> > >>>>>>
> > >>>>>> On Feb 8, 2010, at 10:49 AM, Kermit Kiser wrote:
> > >>>>>>
> > >>>>>>
> > >>>>>>> Hi Bruce;
> > >>>>>>>
> > >>>>>>> 1) I don't know much about Mac stuff. (OK, zero ;-)
> > >>>>>>>
> > >>>>>>> 2) There are three stages to compiling and running a NetRexx
> > >>>>>>> program - first the NetRexx translator (NetRexxC) parses  
> your
> > >>>>>>> code and converts it to Java code, second the translator  
> calls
> > >>>>>>> the Java compiler (javac) to convert the Java code to  
> "bytecode",
> > >>>>>>> third the Java virtual machine loads the bytecode, links  
> it and
> > >>>>>>> executes it. At each stage a different program is handling  
> your
> > >>>>>>> code and each one has to be able to find all the related  
> classes.
> > >>>>>>> Sometimes they don't use the same procedure/path to find  
> things
> > >>>>>>> but generally they will all obey the CLASSPATH environment
> > >>>>>>> variable. Each program has an internal default classpath  
> but the
> > >>>>>>> environment variable will *override* the internal paths.
> > >>>>>>>
> > >>>>>>> 3) Solution: When you specify the CLASSPATH, you must  
> include the
> > >>>>>>> code directory, usually with a "." (a period) or your  
> program
> > >>>>>>> will not be found. Likewise you must include the Java  
> classes and
> > >>>>>>> the NetRexx classes because you are overriding the default  
> paths.
> > >>>>>>>
> > >>>>>>> 4) You can add NetRexxC.jar to the Java extensions  
> directory so
> > >>>>>>> Java can find it in it's default path search but that may  
> not
> > >>>>>>> help NetRexxC to find the classes it needs.
> > >>>>>>>
> > >>>>>>> 5) You may find that it is simpler to install the jEdit  
> IDE with
> > >>>>>>> NetRexxDE and NetRexxScript plugins to compile and interpret
> > >>>>>>> NetRexx code, since the NetRexxC.jar file is automatically
> > >>>>>>> installed that way. (You will still need to download the  
> NetRexx
> > >>>>>>> zip if you want the samples and docs.) If you wish to use  
> the
> > >>>>>>> jEdit environment with the NetRexxScript plugin, be aware  
> that
> > >>>>>>> jEdit uses custom classloaders to dynamically load things.
> > >>>>>>> Therefore if NetRexxC.jar is in the extensions directory  
> for the
> > >>>>>>> Java VM that runs jEdit, NetRexxScript will encounter
> > >>>>>>> "invocation" errors when interpreting scripts due to the  
> conflict
> > >>>>>>> between multiple classloader versions of the NetRexx  
> classes.
> > >>>>>>>
> > >>>>>>> Hope some of this info helps,
> > >>>>>>>
> > >>>>>>> -- Kermit
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> Bruce Skelly wrote:
> > >>>>>>>
> > >>>>>>>> If I understand this correctly, after spending some time  
> playing
> > >>>>>>>> with it, it isn't really that NetRexx doesn't execute  
> unless you
> > >>>>>>>> specify the CLASSPATH.  What I *think* is happening is  
> that the
> > >>>>>>>> NetRexx Compiler, in the course of generating java code  
> needs to
> > >>>>>>>> look at the classes to determine their dependancies.  
> Kind of
> > >>>>>>>> like header files in C.  After the compile is complete, the
> > >>>>>>>> "headers" are no longer needed, and the compiled NetRexx  
> (java)
> > >>>>>>>> program runs just fine without the CLASSPATH.
> > >>>>>>>>
> > >>>>>>>> Please note in my messages, that NetRexxC was executing,  
> but
> > >>>>>>>> issuing error messages stating that it couldn't find things
> > >>>>>>>> (classes).  Also, my compiled NetRexx program executes  
> just fine
> > >>>>>>>> when I unset CLASSPATH, so it can find both the NetRexx  
> runtime,
> > >>>>>>>> and the Java runtime.
> > >>>>>>>>
> > >>>>>>>>
> > >>> _______________________________________________
> > >>> rexxla-members mailing list -- mailto:[hidden email]
> > >>> http://rice.safedataisp.net/mailman/listinfo/rexxla-members
> > >>>
> > >>  
> ------------------------------------------------------------------------
> > >>
> > >> _______________________________________________
> > >> rexxla-members mailing list -- mailto:[hidden email]
> > >> http://rice.safedataisp.net/mailman/listinfo/rexxla-members
> > >>
> > >>
> > > _______________________________________________
> > > rexxla-members mailing list -- mailto:[hidden email]
> > > http://rice.safedataisp.net/mailman/listinfo/rexxla-members
> > >
> > >
> >
> > _______________________________________________
> > Ibm-netrexx mailing list
> > [hidden email]
> >
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ns.hursley.ibm.com/pipermail/ibm-netrexx/attachments/20100210/78c4a974/attachment-0001.html

[Thomas.Schneider.Wien]

An HTML attachment was scrubbed...
URL: http://ns.hursley.ibm.com/pipermail/ibm-netrexx/attachments/20100210/79f4b8f8/attachment.html

[Mike Cowlishaw]

Yes, as far as I recall, NetRexx has to read the .class files themselves
because the Java reflection does not expose everything that's needed to use
a class.   It's possible that reflection has now been improved enough that
the classes could just be loaded.  The current (2000) NetRexx code, however,
has to try and find the class file itself, using whatever information is
available (CLASSPATH, etc.).   Java does not (or did not) help much with
that.  And, indeed, the names of the .jar files changed, so now NetRexx
reads all .jar files it finds, not just the 'JRE' ones.
 
A loop is very surprising, however; I doubt that's in the NetRexx code.
 
Mike


  _____  

From: [hidden email]
[mailto:[hidden email]] On Behalf Of Bruce Skelly
Sent: 10 February 2010 4:07 PM
To: IBM Netrexx
Subject: Re: [Ibm-netrexx] Classpath Environment Var replaced by a java
OPTION!


Alan,

When I execute the compiler NetRexxC with the verbose option, I can see that
the classes.jar file is opened, and the NetRexxC.jar file is opened and
classes are loaded from each of them.  

If I don't have a CLASSPATH defined in the environment, or a -classpath
option set on the command line, the translator loops, looking for what is in
classes.jar and NetRexxC.jar, until it runs out of memory even though it has
them open and has loaded classes from them.

The fact that it loops and doesn't abend/terminate means that the java
runtime is finding all of the classes it needs to execute the program.

Perhaps this internal classpath that java is using isn't exposed to the
program it is running, or if it is exposed, perhaps not in the way that the
program logic expects.

In either case, unless I specify both classes.jar and NetRexxC.jar  in the
CLASSPATH environmental variable, or in the -classpath command line option,
I don't get the compiler to work.

I think the issue is more of a NetRexxC internals issue than it is a java
issue.  I think that the compiler is trying to read the classes, not load
them.  This is a subtile difference, I admit, but can cause java to use
different internal logic.

Bruce  

On Feb 9, 2010, at 10:26 AM, Alan Sampson wrote:


The -classpath option has NOT replaced the CLASSPATH environment variable,
nether is it NEW!  I think it was introduced sometime around Java 1.2 or
1.3.

While we're discussing the -classpath option there's also the -cp,
-Xbootclasspath, -bootclasspath and -jar options (and even
-Djava.class.path=... -Dsun.boot.class.path=... for the terminally perverse)
to name a few that control class loading.  They all play a part in deciding
which (and which order) classes get loaded when a JVM starts.  There is no
one correct way!

Much of the information you're looking for is readily available in the Java
documentation web site, currently
<http://java.sun.com/javase/reference/index.jsp>
http://java.sun.com/javase/reference/index.jsp although since Oracle's
take-over of Sun who knows how long this domain will remain active.

There's a reasonably good tutorial about loading Extension Classes here:
<http://java.sun.com/docs/books/tutorial/ext/basics/index.html>
http://java.sun.com/docs/books/tutorial/ext/basics/index.html with some
specifics of the class loading process here:
<http://java.sun.com/docs/books/tutorial/ext/basics/load.html>
http://java.sun.com/docs/books/tutorial/ext/basics/load.html.

NetRexx is a Java application and thus it must obey the rules of the version
of Java it's running under and that itself is a moving target.  Add to this
any changes introduced by Sun/Oracle as they make improvements in Java to
exploit new technologies there's no guarantee that the old ways will
continue to work.

My point is you must refer to the Java documentation to really understand
how to run NetRexx.  Putting anything specific in the NetRexx documentation
is unlikely to be correct for every existing version of the JDK and will
become obsolete as soon as it's written.

Alan.


[hidden email] wrote on 02/09/2010 05:47:50 AM:

> [image removed]
>
> [Ibm-netrexx] Classpath Environment Var replaced by a java OPTION!
>
> Thomas Schneider
>
> to:
>
> RexxLA Members mailing list
>
> 02/09/2010 06:10 AM
>
> Sent by:
>
> [hidden email]
>
> Cc:
>
> IBM Netrexx
>
> Please respond to IBM Netrexx
>
> Hello Chip & all,
>    you have *NOT* to move any files at all.
>
> I got the info (from Kermit Kiser), that there is a new option
>
> -classpath <classpath>
>
> in the Java Command (and probably also in JavaC and JavaW, but I still
> have to try those).
>
> I still have to try it, but sounds reasonable for me.
>
> I will use it within my batch files ASAP.
> Thomas.
> =================================================================
>
> Chip Davis schrieb:
> > I'm not sure how I feel about Java deprecating the usage of the
> > CLASSPATH variable.
> >
> > IMHO, it is not a good design if you have to move components of one
> > application into the libraries of another component's installation in
> > order to get them to work..
> >
> > Especially when those components are regularly (and frequently)
> > updated.  As soon as you get your NetRexx application development
> > environment up and running, SUN exhorts you to download the latest JDK.

> > I would be quite surprised (but I do not know) if the Java installation
> > routine transfers all the JAR files in the old Java ext/ directory to
> > the new one.
> >
> > So now I've got to (first) remember which NetRexx files need to be
> > copied into which Java directories, and (second) move and test them.  
> > And then deal with the JEdit files, and then the other external NetRexx
> > packages, ... lather, rinse, repeat...  WAPITA.
> >
> > If all that were necessary is to update an environment variable or two,
> > all the installer (for Java, NetRexx, or whatever) would have to do is
> > update the appropriate entries in same, leaving the rest of the entries
> > alone.  PooF!  Everything continues to work as before with the updated
> > component.
> >
> > Requiring an invocation flag that explicitly provides the CLASSPATH is
> > cumbersome (at best) and much too fine a granularity for normal usage.  
> > By all means, provide a mechanism to override the current environment
> > variables on invocation for testing/debugging purposes, but that should
> > not be the preferred technique.
> >
> > -Chip-
> >
> > On 2/9/10 00:58 Bruce Skelly said:
> >  
> >> Kermit,
> >>
> >> I think that we are on the same page now.  The default classpath, does
> >> include a lot of stuff, and yes the current directory is the last
> >> place searched.  
> >>
> >> On Feb 8, 2010, at 12:27 PM, Kermit Kiser wrote:
> >>
> >>    
> >>> Bruce ;
> >>>
> >>> My bad, I guess I failed to make it clear that the default classpaths
> >>> include the period (current directory) and that your classpath is
> >>> deleting it which is causing your problem. When you "unset" the
> >>> CLASSPATH you are actually re-adding the current directory to the
> >>> classpath.
> >>>
> >>> Your logic for not setting the CLASSPATH environment variable is
> >>> exactly why the Java developers deprecated it and added the
> >>> "-classpath" operand to all of the Java commands (java, javac, etc).
> >>>
> >>> -- Kermit
> >>>
> >>> Bruce Skelly wrote:
> >>>      
> >>>> See below
> >>>> On Feb 8, 2010, at 11:50 AM, Kermit Kiser wrote:
> >>>>
> >>>>        
> >>>>> Bruce ;
> >>>>>
> >>>>> Did you read my note? I am pretty sure that if you use the correct
> >>>>> classpath with a period added for the current directory as I
> >>>>> mentioned in item #3 that you will not need to "unset" the
> >>>>> classpath to execute your program.
> >>>>>          
> >>>> Kermit, did you read my note.  I said that the only change I made
> >>>> was to unset the CLASSPATH.  The default CLASSPATH must contain the
> >>>> current directory or some other trickery.   Everything else that is
> >>>> java on my machine seems to work just fine *without* a CLASSPATH.  I
> >>>> choose just set the CLASSPATH for the duration of the NetRexxC.  My
> >>>> concern is that by having a CLASSPATH in the environment, I may
> >>>> cause other things to stop working.  I would then be on an endless
> >>>> journey of tweaking my CLASSPATH so that things work.
> >>>>        
> >>>>> BTW: The CLASSPATH environment variable has been "deprecated" since
> >>>>> Java 1.3 and is not recommended for various reasons. The correct
> >>>>> way to call Java is now with a "-classpath" operand which specifies
> >>>>> the path on the command line. That would give you a much simpler
> >>>>> way to specify the classpath differently in the stages in your
> >>>>> shell script.
> >>>>>
> >>>>> -- Kermit
> >>>>>
> >>>>>
> >>>>> Bruce Skelly wrote:
> >>>>>          
> >>>>>> I don't know, we may be saying the same thing.
> >>>>>>
> >>>>>> I do know that even though both classes.jar and NetRexxC.jar are
> >>>>>> in the default (implicit) CLASSPATH, that NetRexxC would fail
> >>>>>> trying to create the '.java' file.  That is before the java
> >>>>>> compiler is invoked.  In fact, using the -verbose argument to
> >>>>>> java, showed me that many classes were loaded from both .jar files.
> >>>>>>
> >>>>>> If I gave it a CLASSPATH that contained just classes.jar, then it
> >>>>>> would fail, looking for a NetRexx class.  If I gave it a CLASSPATH
> >>>>>> that contained just NetRexxC.jar, it would fail looking for a java
> >>>>>> class.  Specifying both classes.jar and NetRexxC.jar would produce
> >>>>>> a .java file that could then be compiled into a .class file.
> >>>>>>
> >>>>>> At that point if I tried to execute the program, i.e. java
> >>>>>> hello.class, it would fail.  If I then *unset* the CLASSPATH, I
> >>>>>> could then type java hello.class and it would execute.
> >>>>>>
> >>>>>> I modified the distributed NetRexxC.sh file to do this on Darwin
> >>>>>> systems  (Mac OS X), since it appears on my system, CLASSPATH is
> >>>>>> only needed in the translation phase from .nrx to .java.
> >>>>>> ...
> >>>>>> # For Mac OS X with NetRexxC.jar installed in

/Library/Java/Extensions

> >>>>>> if [ "`uname`" = "Darwin" ]
> >>>>>> then
> >>>>>> CLASSPATH=/Library/Java/Extensions/NetRexxC.jar:/System/
> Library/Frameworks/JavaVM.framework/Classes/classes.jar
> >>>>>> export CLASSPATH
> >>>>>> fi
> >>>>>> ...
> >>>>>> # Again for Mac OS X;
> >>>>>> if [ "`uname`" = "Darwin" ]
> >>>>>> then
> >>>>>>      unset CLASSPATH
> >>>>>> fi
> >>>>>> ...
> >>>>>>
> >>>>>> Bruce
> >>>>>>
> >>>>>> On Feb 8, 2010, at 10:49 AM, Kermit Kiser wrote:
> >>>>>>
> >>>>>>            
> >>>>>>> Hi Bruce;
> >>>>>>>
> >>>>>>> 1) I don't know much about Mac stuff. (OK, zero ;-)
> >>>>>>>
> >>>>>>> 2) There are three stages to compiling and running a NetRexx
> >>>>>>> program - first the NetRexx translator (NetRexxC) parses your
> >>>>>>> code and converts it to Java code, second the translator calls
> >>>>>>> the Java compiler (javac) to convert the Java code to "bytecode",
> >>>>>>> third the Java virtual machine loads the bytecode, links it and
> >>>>>>> executes it. At each stage a different program is handling your
> >>>>>>> code and each one has to be able to find all the related classes.
> >>>>>>> Sometimes they don't use the same procedure/path to find things
> >>>>>>> but generally they will all obey the CLASSPATH environment
> >>>>>>> variable. Each program has an internal default classpath but the
> >>>>>>> environment variable will *override* the internal paths.
> >>>>>>>
> >>>>>>> 3) Solution: When you specify the CLASSPATH, you must include the
> >>>>>>> code directory, usually with a "." (a period) or your program
> >>>>>>> will not be found. Likewise you must include the Java classes and
> >>>>>>> the NetRexx classes because you are overriding the default paths.
> >>>>>>>
> >>>>>>> 4) You can add NetRexxC.jar to the Java extensions directory so
> >>>>>>> Java can find it in it's default path search but that may not
> >>>>>>> help NetRexxC to find the classes it needs.
> >>>>>>>
> >>>>>>> 5) You may find that it is simpler to install the jEdit IDE with
> >>>>>>> NetRexxDE and NetRexxScript plugins to compile and interpret
> >>>>>>> NetRexx code, since the NetRexxC.jar file is automatically
> >>>>>>> installed that way. (You will still need to download the NetRexx
> >>>>>>> zip if you want the samples and docs.) If you wish to use the
> >>>>>>> jEdit environment with the NetRexxScript plugin, be aware that
> >>>>>>> jEdit uses custom classloaders to dynamically load things.
> >>>>>>> Therefore if NetRexxC.jar is in the extensions directory for the
> >>>>>>> Java VM that runs jEdit, NetRexxScript will encounter
> >>>>>>> "invocation" errors when interpreting scripts due to the conflict
> >>>>>>> between multiple classloader versions of the NetRexx classes.
> >>>>>>>
> >>>>>>> Hope some of this info helps,
> >>>>>>>
> >>>>>>> -- Kermit
> >>>>>>>
> >>>>>>>
> >>>>>>> Bruce Skelly wrote:
> >>>>>>>              
> >>>>>>>> If I understand this correctly, after spending some time playing
> >>>>>>>> with it, it isn't really that NetRexx doesn't execute unless you
> >>>>>>>> specify the CLASSPATH.  What I *think* is happening is that the
> >>>>>>>> NetRexx Compiler, in the course of generating java code needs to
> >>>>>>>> look at the classes to determine their dependancies.  Kind of
> >>>>>>>> like header files in C.  After the compile is complete, the
> >>>>>>>> "headers" are no longer needed, and the compiled NetRexx (java)
> >>>>>>>> program runs just fine without the CLASSPATH.  
> >>>>>>>>
> >>>>>>>> Please note in my messages, that NetRexxC was executing, but
> >>>>>>>> issuing error messages stating that it couldn't find things
> >>>>>>>> (classes).  Also, my compiled NetRexx program executes just fine
> >>>>>>>> when I unset CLASSPATH, so it can find both the NetRexx runtime,
> >>>>>>>> and the Java runtime.
> >>>>>>>>
> >>>>>>>>                
> >>> _______________________________________________
> >>> rexxla-members mailing list --

<mailto:[hidden email]>
mailto:[hidden email]
> >>>  <http://rice.safedataisp.net/mailman/listinfo/rexxla-members>
http://rice.safedataisp.net/mailman/listinfo/rexxla-members
> >>>      
> >>
------------------------------------------------------------------------
> >>
> >> _______________________________________________
> >> rexxla-members mailing list --  <mailto:[hidden email]>
mailto:[hidden email]
> >>  <http://rice.safedataisp.net/mailman/listinfo/rexxla-members>
http://rice.safedataisp.net/mailman/listinfo/rexxla-members
> >>  
> >>    
> > _______________________________________________
> > rexxla-members mailing list --  <mailto:[hidden email]>
mailto:[hidden email]
> >  <http://rice.safedataisp.net/mailman/listinfo/rexxla-members>
http://rice.safedataisp.net/mailman/listinfo/rexxla-members
> >
> >  
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
>
_______________________________________________
Ibm-netrexx mailing list
[hidden email]




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ns.hursley.ibm.com/pipermail/ibm-netrexx/attachments/20100210/28eefa5c/attachment-0001.html

[Thomas.Schneider.Wien]

An HTML attachment was scrubbed...
URL: http://ns.hursley.ibm.com/pipermail/ibm-netrexx/attachments/20100210/3ad13627/attachment.html

[Mike Cowlishaw]

>  I do no yet know, whether this is a cause  of the Installation  of some
utilities, *or* some new
>  Java  software (which I did), and I am *urgent* seeking (for my own
usage)
>  for a FIX!
>
> For sure, NetREXX doesn't behave like it always did on my machine(s)
 
Tom, NetRexx has not changed.  Therefore, something else on your machine has
changed -- something you did, or something you installed.   There is nothing
Rene, or I, on anyone else on this list, can tell what that is.
 
Why not try System Restore -- go back to a version of your system that
worked?
 
But please stop sending out details of your unique problems with your system
to hundreds of people several times a day.    All you are doing is driving
people away from the list and, therefore, NetRexx.  
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ns.hursley.ibm.com/pipermail/ibm-netrexx/attachments/20100210/81348378/attachment.html

[rvjansen]

Tom,


NetRexx is working fine. Nothing changed. Please check if you did install products (like DB2) that bring their own JVM to the party and make sure you are not scanning whole directories full of jars by having them on the classpath. Make sure that you know what you are executing and avoid having dlls from several JVM's on the executable path.

Do a java -version and see what it tells you. Post it in an email so we can see.

Please show me you classpath setting, and do an nrc -verbose5 compile so we can see what is wrong.

best regards,

Ren?.

On 10 feb 2010, at 19:37, Thomas Schneider wrote:

> Hello Rene,
>    ... could you please clear that up, as soon as possible ! :-)
>    .. and forward you findings, of course.
>
> Currently, I'm recognising some *very strange* behaviours of Mike's (ancient) nrc.bat
> on my machine(s)...
>
>
> I do no yet know, whether this is a cause  of the Installation  of some utilities, *or* some new
> Java  software (which I did), and I am *urgent* seeking (for my own usage)
> for a FIX!
>
> For sure, NetREXX doesn't behave like it always did on my machine(s)
>
> Thomas Schneider.
> ???????????????????????????????????????????????????????????????????????????????????????????????????????
> Mike Cowlishaw schrieb:
>>
>> Yes, as far as I recall, NetRexx has to read the .class files themselves because the Java reflection does not expose everything that's needed to use a class.   It's possible that reflection has now been improved enough that the classes could just be loaded.  The current (2000) NetRexx code, however, has to try and find the class file itself, using whatever information is available (CLASSPATH, etc.).   Java does not (or did not) help much with that.  And, indeed, the names of the .jar files changed, so now NetRexx reads all .jar files it finds, not just the 'JRE' ones.
>>  
>> A loop is very surprising, however; I doubt that's in the NetRexx code.
>>  
>> Mike
>>
>> From: [hidden email] [mailto:[hidden email]] On Behalf Of Bruce Skelly
>> Sent: 10 February 2010 4:07 PM
>> To: IBM Netrexx
>> Subject: Re: [Ibm-netrexx] Classpath Environment Var replaced by a java OPTION!
>>
>> Alan,
>>
>> When I execute the compiler NetRexxC with the verbose option, I can see that the classes.jar file is opened, and the NetRexxC.jar file is opened and classes are loaded from each of them.  
>>
>> If I don't have a CLASSPATH defined in the environment, or a -classpath option set on the command line, the translator loops, looking for what is in classes.jar and NetRexxC.jar, until it runs out of memory even though it has them open and has loaded classes from them.
>>
>> The fact that it loops and doesn't abend/terminate means that the java runtime is finding all of the classes it needs to execute the program.
>>
>> Perhaps this internal classpath that java is using isn't exposed to the program it is running, or if it is exposed, perhaps not in the way that the program logic expects.
>>
>> In either case, unless I specify both classes.jar and NetRexxC.jar  in the CLASSPATH environmental variable, or in the -classpath command line option, I don't get the compiler to work.
>>
>> I think the issue is more of a NetRexxC internals issue than it is a java issue.  I think that the compiler is trying to read the classes, not load them.  This is a subtile difference, I admit, but can cause java to use different internal logic.
>>
>> Bruce  
>>
>> On Feb 9, 2010, at 10:26 AM, Alan Sampson wrote:
>>
>>> The -classpath option has NOT replaced the CLASSPATH environment variable, nether is it NEW!  I think it was introduced sometime around Java 1.2 or 1.3.
>>>
>>> While we're discussing the -classpath option there's also the -cp, -Xbootclasspath, -bootclasspath and -jar options (and even -Djava.class.path=... -Dsun.boot.class.path=... for the terminally perverse) to name a few that control class loading.  They all play a part in deciding which (and which order) classes get loaded when a JVM starts.  There is no one correct way!
>>>
>>> Much of the information you're looking for is readily available in the Java documentation web site, currently http://java.sun.com/javase/reference/index.jsp although since Oracle's take-over of Sun who knows how long this domain will remain active.
>>>
>>> There's a reasonably good tutorial about loading Extension Classes here: http://java.sun.com/docs/books/tutorial/ext/basics/index.html with some specifics of the class loading process here: http://java.sun.com/docs/books/tutorial/ext/basics/load.html.
>>>
>>> NetRexx is a Java application and thus it must obey the rules of the version of Java it's running under and that itself is a moving target.  Add to this any changes introduced by Sun/Oracle as they make improvements in Java to exploit new technologies there's no guarantee that the old ways will continue to work.
>>>
>>> My point is you must refer to the Java documentation to really understand how to run NetRexx.  Putting anything specific in the NetRexx documentation is unlikely to be correct for every existing version of the JDK and will become obsolete as soon as it's written.
>>>
>>> Alan.
>>>
>>>
>>> [hidden email] wrote on 02/09/2010 05:47:50 AM:
>>>
>>> > [image removed]
>>> >
>>> > [Ibm-netrexx] Classpath Environment Var replaced by a java OPTION!
>>> >
>>> > Thomas Schneider
>>> >
>>> > to:
>>> >
>>> > RexxLA Members mailing list
>>> >
>>> > 02/09/2010 06:10 AM
>>> >
>>> > Sent by:
>>> >
>>> > [hidden email]
>>> >
>>> > Cc:
>>> >
>>> > IBM Netrexx
>>> >
>>> > Please respond to IBM Netrexx
>>> >
>>> > Hello Chip & all,
>>> >    you have *NOT* to move any files at all.
>>> >
>>> > I got the info (from Kermit Kiser), that there is a new option
>>> >
>>> > -classpath <classpath>
>>> >
>>> > in the Java Command (and probably also in JavaC and JavaW, but I still
>>> > have to try those).
>>> >
>>> > I still have to try it, but sounds reasonable for me.
>>> >
>>> > I will use it within my batch files ASAP.
>>> > Thomas.
>>> > =================================================================
>>> >
>>> > Chip Davis schrieb:
>>> > > I'm not sure how I feel about Java deprecating the usage of the
>>> > > CLASSPATH variable.
>>> > >
>>> > > IMHO, it is not a good design if you have to move components of one
>>> > > application into the libraries of another component's installation in
>>> > > order to get them to work..
>>> > >
>>> > > Especially when those components are regularly (and frequently)
>>> > > updated.  As soon as you get your NetRexx application development
>>> > > environment up and running, SUN exhorts you to download the latest JDK.  
>>> > > I would be quite surprised (but I do not know) if the Java installation
>>> > > routine transfers all the JAR files in the old Java ext/ directory to
>>> > > the new one.
>>> > >
>>> > > So now I've got to (first) remember which NetRexx files need to be
>>> > > copied into which Java directories, and (second) move and test them.  
>>> > > And then deal with the JEdit files, and then the other external NetRexx
>>> > > packages, ... lather, rinse, repeat...  WAPITA.
>>> > >
>>> > > If all that were necessary is to update an environment variable or two,
>>> > > all the installer (for Java, NetRexx, or whatever) would have to do is
>>> > > update the appropriate entries in same, leaving the rest of the entries
>>> > > alone.  PooF!  Everything continues to work as before with the updated
>>> > > component.
>>> > >
>>> > > Requiring an invocation flag that explicitly provides the CLASSPATH is
>>> > > cumbersome (at best) and much too fine a granularity for normal usage.  
>>> > > By all means, provide a mechanism to override the current environment
>>> > > variables on invocation for testing/debugging purposes, but that should
>>> > > not be the preferred technique.
>>> > >
>>> > > -Chip-
>>> > >
>>> > > On 2/9/10 00:58 Bruce Skelly said:
>>> > >  
>>> > >> Kermit,
>>> > >>
>>> > >> I think that we are on the same page now.  The default classpath, does
>>> > >> include a lot of stuff, and yes the current directory is the last
>>> > >> place searched.  
>>> > >>
>>> > >> On Feb 8, 2010, at 12:27 PM, Kermit Kiser wrote:
>>> > >>
>>> > >>    
>>> > >>> Bruce ;
>>> > >>>
>>> > >>> My bad, I guess I failed to make it clear that the default classpaths
>>> > >>> include the period (current directory) and that your classpath is
>>> > >>> deleting it which is causing your problem. When you "unset" the
>>> > >>> CLASSPATH you are actually re-adding the current directory to the
>>> > >>> classpath.
>>> > >>>
>>> > >>> Your logic for not setting the CLASSPATH environment variable is
>>> > >>> exactly why the Java developers deprecated it and added the
>>> > >>> "-classpath" operand to all of the Java commands (java, javac, etc).
>>> > >>>
>>> > >>> -- Kermit
>>> > >>>
>>> > >>> Bruce Skelly wrote:
>>> > >>>      
>>> > >>>> See below
>>> > >>>> On Feb 8, 2010, at 11:50 AM, Kermit Kiser wrote:
>>> > >>>>
>>> > >>>>        
>>> > >>>>> Bruce ;
>>> > >>>>>
>>> > >>>>> Did you read my note? I am pretty sure that if you use the correct
>>> > >>>>> classpath with a period added for the current directory as I
>>> > >>>>> mentioned in item #3 that you will not need to "unset" the
>>> > >>>>> classpath to execute your program.
>>> > >>>>>          
>>> > >>>> Kermit, did you read my note.  I said that the only change I made
>>> > >>>> was to unset the CLASSPATH.  The default CLASSPATH must contain the
>>> > >>>> current directory or some other trickery.   Everything else that is
>>> > >>>> java on my machine seems to work just fine *without* a CLASSPATH.  I
>>> > >>>> choose just set the CLASSPATH for the duration of the NetRexxC.  My
>>> > >>>> concern is that by having a CLASSPATH in the environment, I may
>>> > >>>> cause other things to stop working.  I would then be on an endless
>>> > >>>> journey of tweaking my CLASSPATH so that things work.
>>> > >>>>        
>>> > >>>>> BTW: The CLASSPATH environment variable has been "deprecated" since
>>> > >>>>> Java 1.3 and is not recommended for various reasons. The correct
>>> > >>>>> way to call Java is now with a "-classpath" operand which specifies
>>> > >>>>> the path on the command line. That would give you a much simpler
>>> > >>>>> way to specify the classpath differently in the stages in your
>>> > >>>>> shell script.
>>> > >>>>>
>>> > >>>>> -- Kermit
>>> > >>>>>
>>> > >>>>>
>>> > >>>>> Bruce Skelly wrote:
>>> > >>>>>          
>>> > >>>>>> I don't know, we may be saying the same thing.
>>> > >>>>>>
>>> > >>>>>> I do know that even though both classes.jar and NetRexxC.jar are
>>> > >>>>>> in the default (implicit) CLASSPATH, that NetRexxC would fail
>>> > >>>>>> trying to create the '.java' file.  That is before the java
>>> > >>>>>> compiler is invoked.  In fact, using the -verbose argument to
>>> > >>>>>> java, showed me that many classes were loaded from both .jar files.
>>> > >>>>>>
>>> > >>>>>> If I gave it a CLASSPATH that contained just classes.jar, then it
>>> > >>>>>> would fail, looking for a NetRexx class.  If I gave it a CLASSPATH
>>> > >>>>>> that contained just NetRexxC.jar, it would fail looking for a java
>>> > >>>>>> class.  Specifying both classes.jar and NetRexxC.jar would produce
>>> > >>>>>> a .java file that could then be compiled into a .class file.
>>> > >>>>>>
>>> > >>>>>> At that point if I tried to execute the program, i.e. java
>>> > >>>>>> hello.class, it would fail.  If I then *unset* the CLASSPATH, I
>>> > >>>>>> could then type java hello.class and it would execute.
>>> > >>>>>>
>>> > >>>>>> I modified the distributed NetRexxC.sh file to do this on Darwin
>>> > >>>>>> systems  (Mac OS X), since it appears on my system, CLASSPATH is
>>> > >>>>>> only needed in the translation phase from .nrx to .java.
>>> > >>>>>> ...
>>> > >>>>>> # For Mac OS X with NetRexxC.jar installed in /Library/Java/Extensions
>>> > >>>>>> if [ "`uname`" = "Darwin" ]
>>> > >>>>>> then
>>> > >>>>>> CLASSPATH=/Library/Java/Extensions/NetRexxC.jar:/System/
>>> > Library/Frameworks/JavaVM.framework/Classes/classes.jar
>>> > >>>>>> export CLASSPATH
>>> > >>>>>> fi
>>> > >>>>>> ...
>>> > >>>>>> # Again for Mac OS X;
>>> > >>>>>> if [ "`uname`" = "Darwin" ]
>>> > >>>>>> then
>>> > >>>>>>      unset CLASSPATH
>>> > >>>>>> fi
>>> > >>>>>> ...
>>> > >>>>>>
>>> > >>>>>> Bruce
>>> > >>>>>>
>>> > >>>>>> On Feb 8, 2010, at 10:49 AM, Kermit Kiser wrote:
>>> > >>>>>>
>>> > >>>>>>            
>>> > >>>>>>> Hi Bruce;
>>> > >>>>>>>
>>> > >>>>>>> 1) I don't know much about Mac stuff. (OK, zero ;-)
>>> > >>>>>>>
>>> > >>>>>>> 2) There are three stages to compiling and running a NetRexx
>>> > >>>>>>> program - first the NetRexx translator (NetRexxC) parses your
>>> > >>>>>>> code and converts it to Java code, second the translator calls
>>> > >>>>>>> the Java compiler (javac) to convert the Java code to "bytecode",
>>> > >>>>>>> third the Java virtual machine loads the bytecode, links it and
>>> > >>>>>>> executes it. At each stage a different program is handling your
>>> > >>>>>>> code and each one has to be able to find all the related classes.
>>> > >>>>>>> Sometimes they don't use the same procedure/path to find things
>>> > >>>>>>> but generally they will all obey the CLASSPATH environment
>>> > >>>>>>> variable. Each program has an internal default classpath but the
>>> > >>>>>>> environment variable will *override* the internal paths.
>>> > >>>>>>>
>>> > >>>>>>> 3) Solution: When you specify the CLASSPATH, you must include the
>>> > >>>>>>> code directory, usually with a "." (a period) or your program
>>> > >>>>>>> will not be found. Likewise you must include the Java classes and
>>> > >>>>>>> the NetRexx classes because you are overriding the default paths.
>>> > >>>>>>>
>>> > >>>>>>> 4) You can add NetRexxC.jar to the Java extensions directory so
>>> > >>>>>>> Java can find it in it's default path search but that may not
>>> > >>>>>>> help NetRexxC to find the classes it needs.
>>> > >>>>>>>
>>> > >>>>>>> 5) You may find that it is simpler to install the jEdit IDE with
>>> > >>>>>>> NetRexxDE and NetRexxScript plugins to compile and interpret
>>> > >>>>>>> NetRexx code, since the NetRexxC.jar file is automatically
>>> > >>>>>>> installed that way. (You will still need to download the NetRexx
>>> > >>>>>>> zip if you want the samples and docs.) If you wish to use the
>>> > >>>>>>> jEdit environment with the NetRexxScript plugin, be aware that
>>> > >>>>>>> jEdit uses custom classloaders to dynamically load things.
>>> > >>>>>>> Therefore if NetRexxC.jar is in the extensions directory for the
>>> > >>>>>>> Java VM that runs jEdit, NetRexxScript will encounter
>>> > >>>>>>> "invocation" errors when interpreting scripts due to the conflict
>>> > >>>>>>> between multiple classloader versions of the NetRexx classes.
>>> > >>>>>>>
>>> > >>>>>>> Hope some of this info helps,
>>> > >>>>>>>
>>> > >>>>>>> -- Kermit
>>> > >>>>>>>
>>> > >>>>>>>
>>> > >>>>>>> Bruce Skelly wrote:
>>> > >>>>>>>              
>>> > >>>>>>>> If I understand this correctly, after spending some time playing
>>> > >>>>>>>> with it, it isn't really that NetRexx doesn't execute unless you
>>> > >>>>>>>> specify the CLASSPATH.  What I *think* is happening is that the
>>> > >>>>>>>> NetRexx Compiler, in the course of generating java code needs to
>>> > >>>>>>>> look at the classes to determine their dependancies.  Kind of
>>> > >>>>>>>> like header files in C.  After the compile is complete, the
>>> > >>>>>>>> "headers" are no longer needed, and the compiled NetRexx (java)
>>> > >>>>>>>> program runs just fine without the CLASSPATH.  
>>> > >>>>>>>>
>>> > >>>>>>>> Please note in my messages, that NetRexxC was executing, but
>>> > >>>>>>>> issuing error messages stating that it couldn't find things
>>> > >>>>>>>> (classes).  Also, my compiled NetRexx program executes just fine
>>> > >>>>>>>> when I unset CLASSPATH, so it can find both the NetRexx runtime,
>>> > >>>>>>>> and the Java runtime.
>>> > >>>>>>>>
>>> > >>>>>>>>                
>>> > >>> _______________________________________________
>>> > >>> rexxla-members mailing list -- mailto:[hidden email]
>>> > >>> http://rice.safedataisp.net/mailman/listinfo/rexxla-members
>>> > >>>      
>>> > >> ------------------------------------------------------------------------
>>> > >>
>>> > >> _______________________________________________
>>> > >> rexxla-members mailing list -- mailto:[hidden email]
>>> > >> http://rice.safedataisp.net/mailman/listinfo/rexxla-members
>>> > >>  
>>> > >>    
>>> > > _______________________________________________
>>> > > rexxla-members mailing list -- mailto:[hidden email]
>>> > > http://rice.safedataisp.net/mailman/listinfo/rexxla-members
>>> > >
>>> > >  
>>> >
>>> > _______________________________________________
>>> > Ibm-netrexx mailing list
>>> > [hidden email]
>>> >
>>> _______________________________________________
>>> Ibm-netrexx mailing list
>>> [hidden email]
>>>
>>
>>
>> _______________________________________________
>> Ibm-netrexx mailing list
>> [hidden email]
>>
>>  
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ns.hursley.ibm.com/pipermail/ibm-netrexx/attachments/20100210/2b77d12b/attachment-0001.html

[David Requena]

Hi All,

I guess this is gonna be just another proposal for documentation updating when the time comes. First the intro...

Remeber this issue Bruce had getting NetRexxC stuck into a loop? He workarounded it by using different
classpaths for compilation an running of NetRexx programs.

After much mucking around with this in NetRexxDE, with which Bruce was having the problem too, the culprit
has been found to be the compiler behaviour Mike describes bellow. In short NetRexxC does scan the classpath
and actually 'read' any classes found.

The compiler wasn't getting into a loop at all. Bruce was including the current directory ('.') in the classpath. In
addition his hello.nrx was located at the top of his home directory which contained tons of other files as well as
symbolic links pointing elsewhere in his system. This kept the compiler busy scanning most of his hard disk, jars
and zips until the jvm ran out of heap. Some actual loop due to symlinks pointing back to pre-scanned directories
is also possible, although unconfirmed.

So here is our proposal (Bruce's in fact, but I second it!):

If recent improvements in reflection do not allow for this behaviour to be modified, it should at least be documented.
A prominent note should also be added advising PBUs and newbies alike to put their nrx files into their own
directory/folder when putting '.' in the classpath.


El 10/02/2010 17:55, Mike Cowlishaw escribió:

Yes, as far as I recall, NetRexx has to read the .class files themselves because the Java reflection does not expose everything that's needed to use a class.   It's possible that reflection has now been improved enough that the classes could just be loaded.  The current (2000) NetRexx code, however, has to try and find the class file itself, using whatever information is available (CLASSPATH, etc.).   Java does not (or did not) help much with that.  And, indeed, the names of the .jar files changed, so now NetRexx reads all .jar files it finds, not just the 'JRE' ones.

 

A loop is very surprising, however; I doubt that's in the NetRexx code.

 

Mike

---

From: [hidden email] [[hidden email]] On Behalf Of Bruce Skelly
Sent: 10 February 2010 4:07 PM
To: IBM Netrexx
Subject: Re: [Ibm-netrexx] Classpath Environment Var replaced by a java OPTION!

Alan,

When I execute the compiler NetRexxC with the verbose option, I can see that the classes.jar file is opened, and the NetRexxC.jar file is opened and classes are loaded from each of them.  

If I don't have a CLASSPATH defined in the environment, or a -classpath option set on the command line, the translator loops, looking for what is in classes.jar and NetRexxC.jar, until it runs out of memory even though it has them open and has loaded classes from them.

The fact that it loops and doesn't abend/terminate means that the java runtime is finding all of the classes it needs to execute the program.

Perhaps this internal classpath that java is using isn't exposed to the program it is running, or if it is exposed, perhaps not in the way that the program logic expects.

In either case, unless I specify both classes.jar and NetRexxC.jar  in the CLASSPATH environmental variable, or in the -classpath command line option, I don't get the compiler to work.

I think the issue is more of a NetRexxC internals issue than it is a java issue.  I think that the compiler is trying to read the classes, not load them.  This is a subtile difference, I admit, but can cause java to use different internal logic.

Bruce  

On Feb 9, 2010, at 10:26 AM, Alan Sampson wrote:

The -classpath option has NOT replaced the CLASSPATH environment variable, nether is it NEW!  I think it was introduced sometime around Java 1.2 or 1.3.

While we're discussing the -classpath option there's also the -cp, -Xbootclasspath, -bootclasspath and -jar options (and even -Djava.class.path=... -Dsun.boot.class.path=... for the terminally perverse) to name a few that control class loading.  They all play a part in deciding which (and which order) classes get loaded when a JVM starts.  There is no one correct way!

Much of the information you're looking for is readily available in the Java documentation web site, currently http://java.sun.com/javase/reference/index.jsp although since Oracle's take-over of Sun who knows how long this domain will remain active.

There's a reasonably good tutorial about loading Extension Classes here: http://java.sun.com/docs/books/tutorial/ext/basics/index.html with some specifics of the class loading process here: http://java.sun.com/docs/books/tutorial/ext/basics/load.html.

NetRexx is a Java application and thus it must obey the rules of the version of Java it's running under and that itself is a moving target.  Add to this any changes introduced by Sun/Oracle as they make improvements in Java to exploit new technologies there's no guarantee that the old ways will continue to work.

My point is you must refer to the Java documentation to really understand how to run NetRexx.  Putting anything specific in the NetRexx documentation is unlikely to be correct for every existing version of the JDK and will become obsolete as soon as it's written.

Alan.


[hidden email] wrote on 02/09/2010 05:47:50 AM:

> [image removed]
>
> [Ibm-netrexx] Classpath Environment Var replaced by a java OPTION!
>
> Thomas Schneider
>
> to:
>
> RexxLA Members mailing list
>
> 02/09/2010 06:10 AM
>
> Sent by:
>
> [hidden email]
>
> Cc:
>
> IBM Netrexx
>
> Please respond to IBM Netrexx
>
> Hello Chip & all,
>    you have *NOT* to move any files at all.
>
> I got the info (from Kermit Kiser), that there is a new option
>
> -classpath <classpath>
>
> in the Java Command (and probably also in JavaC and JavaW, but I still
> have to try those).
>
> I still have to try it, but sounds reasonable for me.
>
> I will use it within my batch files ASAP.
> Thomas.
> =================================================================
>
> Chip Davis schrieb:
> > I'm not sure how I feel about Java deprecating the usage of the
> > CLASSPATH variable.
> >
> > IMHO, it is not a good design if you have to move components of one
> > application into the libraries of another component's installation in
> > order to get them to work..
> >
> > Especially when those components are regularly (and frequently)
> > updated.  As soon as you get your NetRexx application development
> > environment up and running, SUN exhorts you to download the latest JDK.  
> > I would be quite surprised (but I do not know) if the Java installation
> > routine transfers all the JAR files in the old Java ext/ directory to
> > the new one.
> >
> > So now I've got to (first) remember which NetRexx files need to be
> > copied into which Java directories, and (second) move and test them.  
> > And then deal with the JEdit files, and then the other external NetRexx
> > packages, ... lather, rinse, repeat...  WAPITA.
> >
> > If all that were necessary is to update an environment variable or two,
> > all the installer (for Java, NetRexx, or whatever) would have to do is
> > update the appropriate entries in same, leaving the rest of the entries
> > alone.  PooF!  Everything continues to work as before with the updated
> > component.
> >
> > Requiring an invocation flag that explicitly provides the CLASSPATH is
> > cumbersome (at best) and much too fine a granularity for normal usage.  
> > By all means, provide a mechanism to override the current environment
> > variables on invocation for testing/debugging purposes, but that should
> > not be the preferred technique.
> >
> > -Chip-
> >
> > On 2/9/10 00:58 Bruce Skelly said:
> >  
> >> Kermit,
> >>
> >> I think that we are on the same page now.  The default classpath, does
> >> include a lot of stuff, and yes the current directory is the last
> >> place searched.  
> >>
> >> On Feb 8, 2010, at 12:27 PM, Kermit Kiser wrote:
> >>
> >>    
> >>> Bruce ;
> >>>
> >>> My bad, I guess I failed to make it clear that the default classpaths
> >>> include the period (current directory) and that your classpath is
> >>> deleting it which is causing your problem. When you "unset" the
> >>> CLASSPATH you are actually re-adding the current directory to the
> >>> classpath.
> >>>
> >>> Your logic for not setting the CLASSPATH environment variable is
> >>> exactly why the Java developers deprecated it and added the
> >>> "-classpath" operand to all of the Java commands (java, javac, etc).
> >>>
> >>> -- Kermit
> >>>
> >>> Bruce Skelly wrote:
> >>>      
> >>>> See below
> >>>> On Feb 8, 2010, at 11:50 AM, Kermit Kiser wrote:
> >>>>
> >>>>        
> >>>>> Bruce ;
> >>>>>
> >>>>> Did you read my note? I am pretty sure that if you use the correct
> >>>>> classpath with a period added for the current directory as I
> >>>>> mentioned in item #3 that you will not need to "unset" the
> >>>>> classpath to execute your program.
> >>>>>          
> >>>> Kermit, did you read my note.  I said that the only change I made
> >>>> was to unset the CLASSPATH.  The default CLASSPATH must contain the
> >>>> current directory or some other trickery.   Everything else that is
> >>>> java on my machine seems to work just fine *without* a CLASSPATH.  I
> >>>> choose just set the CLASSPATH for the duration of the NetRexxC.  My
> >>>> concern is that by having a CLASSPATH in the environment, I may
> >>>> cause other things to stop working.  I would then be on an endless
> >>>> journey of tweaking my CLASSPATH so that things work.
> >>>>        
> >>>>> BTW: The CLASSPATH environment variable has been "deprecated" since
> >>>>> Java 1.3 and is not recommended for various reasons. The correct
> >>>>> way to call Java is now with a "-classpath" operand which specifies
> >>>>> the path on the command line. That would give you a much simpler
> >>>>> way to specify the classpath differently in the stages in your
> >>>>> shell script.
> >>>>>
> >>>>> -- Kermit
> >>>>>
> >>>>>
> >>>>> Bruce Skelly wrote:
> >>>>>          
> >>>>>> I don't know, we may be saying the same thing.
> >>>>>>
> >>>>>> I do know that even though both classes.jar and NetRexxC.jar are
> >>>>>> in the default (implicit) CLASSPATH, that NetRexxC would fail
> >>>>>> trying to create the '.java' file.  That is before the java
> >>>>>> compiler is invoked.  In fact, using the -verbose argument to
> >>>>>> java, showed me that many classes were loaded from both .jar files.
> >>>>>>
> >>>>>> If I gave it a CLASSPATH that contained just classes.jar, then it
> >>>>>> would fail, looking for a NetRexx class.  If I gave it a CLASSPATH
> >>>>>> that contained just NetRexxC.jar, it would fail looking for a java
> >>>>>> class.  Specifying both classes.jar and NetRexxC.jar would produce
> >>>>>> a .java file that could then be compiled into a .class file.
> >>>>>>
> >>>>>> At that point if I tried to execute the program, i.e. java
> >>>>>> hello.class, it would fail.  If I then *unset* the CLASSPATH, I
> >>>>>> could then type java hello.class and it would execute.
> >>>>>>
> >>>>>> I modified the distributed NetRexxC.sh file to do this on Darwin
> >>>>>> systems  (Mac OS X), since it appears on my system, CLASSPATH is
> >>>>>> only needed in the translation phase from .nrx to .java.
> >>>>>> ...
> >>>>>> # For Mac OS X with NetRexxC.jar installed in /Library/Java/Extensions
> >>>>>> if [ "`uname`" = "Darwin" ]
> >>>>>> then
> >>>>>> CLASSPATH=/Library/Java/Extensions/NetRexxC.jar:/System/
> Library/Frameworks/JavaVM.framework/Classes/classes.jar
> >>>>>> export CLASSPATH
> >>>>>> fi
> >>>>>> ...
> >>>>>> # Again for Mac OS X;
> >>>>>> if [ "`uname`" = "Darwin" ]
> >>>>>> then
> >>>>>>      unset CLASSPATH
> >>>>>> fi
> >>>>>> ...
> >>>>>>
> >>>>>> Bruce
> >>>>>>
> >>>>>> On Feb 8, 2010, at 10:49 AM, Kermit Kiser wrote:
> >>>>>>
> >>>>>>            
> >>>>>>> Hi Bruce;
> >>>>>>>
> >>>>>>> 1) I don't know much about Mac stuff. (OK, zero ;-)
> >>>>>>>
> >>>>>>> 2) There are three stages to compiling and running a NetRexx
> >>>>>>> program - first the NetRexx translator (NetRexxC) parses your
> >>>>>>> code and converts it to Java code, second the translator calls
> >>>>>>> the Java compiler (javac) to convert the Java code to "bytecode",
> >>>>>>> third the Java virtual machine loads the bytecode, links it and
> >>>>>>> executes it. At each stage a different program is handling your
> >>>>>>> code and each one has to be able to find all the related classes.
> >>>>>>> Sometimes they don't use the same procedure/path to find things
> >>>>>>> but generally they will all obey the CLASSPATH environment
> >>>>>>> variable. Each program has an internal default classpath but the
> >>>>>>> environment variable will *override* the internal paths.
> >>>>>>>
> >>>>>>> 3) Solution: When you specify the CLASSPATH, you must include the
> >>>>>>> code directory, usually with a "." (a period) or your program
> >>>>>>> will not be found. Likewise you must include the Java classes and
> >>>>>>> the NetRexx classes because you are overriding the default paths.
> >>>>>>>
> >>>>>>> 4) You can add NetRexxC.jar to the Java extensions directory so
> >>>>>>> Java can find it in it's default path search but that may not
> >>>>>>> help NetRexxC to find the classes it needs.
> >>>>>>>
> >>>>>>> 5) You may find that it is simpler to install the jEdit IDE with
> >>>>>>> NetRexxDE and NetRexxScript plugins to compile and interpret
> >>>>>>> NetRexx code, since the NetRexxC.jar file is automatically
> >>>>>>> installed that way. (You will still need to download the NetRexx
> >>>>>>> zip if you want the samples and docs.) If you wish to use the
> >>>>>>> jEdit environment with the NetRexxScript plugin, be aware that
> >>>>>>> jEdit uses custom classloaders to dynamically load things.
> >>>>>>> Therefore if NetRexxC.jar is in the extensions directory for the
> >>>>>>> Java VM that runs jEdit, NetRexxScript will encounter
> >>>>>>> "invocation" errors when interpreting scripts due to the conflict
> >>>>>>> between multiple classloader versions of the NetRexx classes.
> >>>>>>>
> >>>>>>> Hope some of this info helps,
> >>>>>>>
> >>>>>>> -- Kermit
> >>>>>>>
> >>>>>>>
> >>>>>>> Bruce Skelly wrote:
> >>>>>>>              
> >>>>>>>> If I understand this correctly, after spending some time playing
> >>>>>>>> with it, it isn't really that NetRexx doesn't execute unless you
> >>>>>>>> specify the CLASSPATH.  What I *think* is happening is that the
> >>>>>>>> NetRexx Compiler, in the course of generating java code needs to
> >>>>>>>> look at the classes to determine their dependancies.  Kind of
> >>>>>>>> like header files in C.  After the compile is complete, the
> >>>>>>>> "headers" are no longer needed, and the compiled NetRexx (java)
> >>>>>>>> program runs just fine without the CLASSPATH.  
> >>>>>>>>
> >>>>>>>> Please note in my messages, that NetRexxC was executing, but
> >>>>>>>> issuing error messages stating that it couldn't find things
> >>>>>>>> (classes).  Also, my compiled NetRexx program executes just fine
> >>>>>>>> when I unset CLASSPATH, so it can find both the NetRexx runtime,
> >>>>>>>> and the Java runtime.
> >>>>>>>>
> >>>>>>>>                
> >>> _______________________________________________
> >>> rexxla-members mailing list -- [hidden email]
> >>> http://rice.safedataisp.net/mailman/listinfo/rexxla-members
> >>>      
> >> ------------------------------------------------------------------------
> >>
> >> _______________________________________________
> >> rexxla-members mailing list -- [hidden email]
> >> http://rice.safedataisp.net/mailman/listinfo/rexxla-members
> >>  
> >>    
> > _______________________________________________
> > rexxla-members mailing list -- [hidden email]
> > http://rice.safedataisp.net/mailman/listinfo/rexxla-members
> >
> >  
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
>
_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

  

_______________________________________________
Ibm-netrexx mailing list
[hidden email]