Call for help with tools.jar locater algorithm.

[Kermit Kiser]

Per a recent discussion with Bill, locating tools.jar or the equivalent
classes.jar for Mac is a common problem to IDE setups as well as the
requested NetRexx installer. As a first step toward creating a suitable
algorithm usable by installers for locating the Java compiler, I have
drafted a small Java environment scanner that will report any possible
locations it finds.

If you have time, please run this scanner on any Java system you have
available and post the output back to the list. I am particularly
interested in Mac output since I have no access to such systems. Also
any JDK locations the program misses. This program does NOT require that
NetRexx be installed to run it - just download the binary file and start
it with "java envirotest". Here is the binary class file link and the
source is below that:

http://kenai.com/projects/netrexx-plus/downloads/download/Envirotest/envirotest.class


(Please pardon the odd property and method names - I seem to have been
in a whimsical mood when I wrote it. )

-- Kermit

options binary
class envirotest
--                                        This program written by Kermit
Kiser on 2011/09/21 is placed in the public domain.

properties static

      java_version=String
      java_home=String
      java_class_path=String
      java_library_path=String
      java_ext_dirs=String
      os_name=String
      os_arch=String
      os_version=String

     f=System.getProperty('file.separator')
     s=System.getProperty('path.separator')

  method main(sa=String[]) static

      System.out.println("NetRexx Envirotest version 1.0")

      badabing

      badaboom

  method badabing static

      java_version=System.getProperty("java.version")
      System.out.println("java.version:" System.getProperty("java.version"))

     java_home= System.getProperty("java.home")
      System.out.println("java.home:" System.getProperty("java.home"))

      java_class_path= System.getProperty("java.class.path")
      System.out.println("java.class.path:"
System.getProperty("java.class.path"))

     java_library_path= System.getProperty("java.library.path")
      System.out.println("java.library.path:"
System.getProperty("java.library.path"))

     java_ext_dirs= System.getProperty("java.ext.dirs")
      System.out.println("java.ext.dirs:"
System.getProperty("java.ext.dirs"))

     os_name= System.getProperty("os.name")
      System.out.println("os.name:" System.getProperty("os.name"))

     os_arch= System.getProperty("os.arch")
      System.out.println("os.arch:" System.getProperty("os.arch"))

     os_version= System.getProperty("os.version")
      System.out.println("os.version:" System.getProperty("os.version"))

method badaboom static

     -- check java.home for a copy of tools.jar
     bondukey(java_home)

     --    and up one directory to look for jdk dirs
     phone_home=File(java_home).getParent
     bondukey(phone_home)
     conlist=File(phone_home).list
     loop i=0 for conlist.length
         tf=File(phone_home||f||conlist[i])
         if tf.isDirectory then bondukey(tf.getPath)
         end

     --    check if tools.jar has been added to an extension directory
     e=java_ext_dirs
     loop for 9
         p=e.indexOf(s)
         if p>=0 then do
             p1=e.substring(0,p)
             e=e.substring(p+1)
             flambam(p1||f"tools.jar")
             end
         else do
             flambam(e||f"tools.jar")
             leave
             end
         end

method flambam(burnbom=String) static

     if File(burnbom).exists then System.out.println("found:"burnbom)

method bondukey(durphon=String) static

     flambam(durphon||f"tools.jar")
     flambam(durphon||f"lib"f"tools.jar")
     flambam(durphon||f"lib"f"ext"f"tools.jar")
     flambam(durphon||f"bundle"f"Classes"f"classes.jar")
     flambam(durphon||f"Classes"f"classes.jar")
     flambam(durphon||f"classes.jar")

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[billfen]

Kermit,
I've run your program in the Eclipse environment in both the production and
development (debug) versions.  Here are the results - almost identical as
might be expected.

NetRexx portable processor, version NetRexx 3.01RC1, build 40-20110905-2355
Copyright (c) RexxLA, 2011.  All rights reserved.
Parts Copyright (c) IBM Corporation, 1995,2008.
Program envirotest.nrx
  === class envirotest ===
    function main(String[])
    function badabing
    function badaboom
    function flambam(String)
    function bondukey(String)
===== Exec: envirotest =====
NetRexx Envirotest version 1.0
java.version: 1.6.0_27
java.home: C:\Program Files\Java\jdk1.6.0_27\jre
java.class.path: F:\EclipseNetRexx\E 3.6.2
Test\eclipse\configuration\org.eclipse.osgi\bundles\4\1\.cp\jars\NetRexxC.ja
r
java.library.path: C:\Program
Files\Java\jdk1.6.0_27\bin;C:\WINDOWS\Sun\Java\bin;C:\WINDOWS\system32;C:\WI
NDOWS;C:/Program Files/Java/jre6/bin/client;C:/Program
Files/Java/jre6/bin;C:/Program
Files/Java/jre6/lib/i386;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\
Wbem;C:\WINDOWS\system32\WindowsPowerShell\v1.0;C:\WINDOWS\system32\WindowsP
owerShell\v1.0;C:\cygwin\bin;F:\EclipseNetRexx\E 3.6.2 Test\eclipse;;.
java.ext.dirs: C:\Program
Files\Java\jdk1.6.0_27\jre\lib\ext;C:\WINDOWS\Sun\Java\lib\ext
os.name: Windows XP
os.arch: x86
os.version: 5.1
found:C:\Program Files\Java\jdk1.6.0_27\lib\tools.jar
found:C:\Program Files\Java\jdk1.6.0_27\lib\tools.jar
Processing of 'envirotest.nrx' complete

----------------------------------------------------------------
NetRexx portable processor, version NetRexx 3.01RC1, build 40-20110905-2355
Copyright (c) RexxLA, 2011.  All rights reserved.
Parts Copyright (c) IBM Corporation, 1995,2008.
Program envirotest.nrx
  === class envirotest ===
    function main(String[])
    function badabing
    function badaboom
    function flambam(String)
    function bondukey(String)
===== Exec: envirotest =====
NetRexx Envirotest version 1.0
java.version: 1.6.0_27
java.home: C:\Program Files\Java\jdk1.6.0_27\jre
java.class.path: F:\EclipseNetRexx\E 3.6.2
NetRexx\workspace\eclipsenetrexx\jars\NetRexxC.jar
java.library.path: C:\Program
Files\Java\jdk1.6.0_27\bin;C:\WINDOWS\Sun\Java\bin;C:\WINDOWS\system32;C:\WI
NDOWS;C:\Program Files\Java\jdk1.6.0_27\jre\bin;C:/Program
Files/Java/jre6/bin/client;C:/Program Files/Java/jre6/bin;C:/Program
Files/Java/jre6/lib/i386;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\
Wbem;C:\WINDOWS\system32\WindowsPowerShell\v1.0;C:\WINDOWS\system32\WindowsP
owerShell\v1.0;C:\cygwin\bin;F:\EclipseNetRexx\E 3.6.2 NetRexx\eclipse;;.
java.ext.dirs: C:\Program
Files\Java\jdk1.6.0_27\jre\lib\ext;C:\WINDOWS\Sun\Java\lib\ext
os.name: Windows XP
os.arch: x86
os.version: 5.1
found:C:\Program Files\Java\jdk1.6.0_27\lib\tools.jar
found:C:\Program Files\Java\jdk1.6.0_27\lib\tools.jar
Processing of 'envirotest.nrx' complete

--------------------------------------------------------------

Perhaps Rene will comment regarding the Mac - he uses one.

To handle this problem in the Eclipse plugin, I provide a user settable
compiler classpath option.  To set the default, I try to guess the location
by taking assuming that the JDK JRE has been specified in JAVA_HOME or
java.home, and replacing "\jre" with "\lib\tools.jar".  That sort of works
for windows - on the Mac (based on what Rene told me), no compiler
classpath is necessary.  I don't know about *nix systems.  Allowing the
user to set the compiler classpath directly mostly solves the problem for
the Eclipse situation, and I agree it is better if it can be done
automatically.

--------------------------------------------------------------------
mail2web.com – What can On Demand Business Solutions do for you?
http://link.mail2web.com/Business/SharePoint



_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Dave Woodman]

Hi Kermit,

I have both the "standard" JDK and the J2EE JDK installed (in c:\glassfish3)

The tool correctly identified the J2SE JDK, as per the output below.

NetRexx Envirotest version 1.0
java.version: 1.6.0_27
java.home: C:\Program Files (x86)\Java\jdk1.6.0_27\jre
java.class.path: .
java.library.path: C:\Program Files
(x86)\Java\jdk1.6.0_27\bin;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Wi
ndows;C:\Program
Files\ImageMagick-6.6.6-Q16;C:\Windows\system32;C:\Windows;C:\Windows\System
32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files
(x86)\Lenovo\Access Connections\;C:\Program Files (x86)\Common
Files\Lenovo;C:\Program Files\Common Files\Lenovo;C:\Program Files
(x86)\Lenovo\Client Security Solution;C:\Program Files\Lenovo\Client
Security Solution;C:\Program Files\ThinkPad\Bluetooth Software\;C:\Program
Files\ThinkPad\Bluetooth Software\syswow64;C:\SWTOOLS\ReadyApps;C:\Program
Files\ooRexx;C:\Program Files (x86)\Calibre2\;"C:\Program Files
(x86)\Zend\ZendServer\bin";"C:\Program Files
(x86)\Zend\ZendServer\share\ZendFramework\bin";C:\Program
Files\TortoiseSVN\bin;C:\Program Files\SlikSvn\bin\;C:\Program
Files\jEdit;C:\Program Files (x86)\QuickTime\QTSystem\;C:\Program Files
(x86)\OpenVPN\bin;C:\Program Files
(x86)\Java\jdk1.6.0_27\bin;c:\glassfish3\jdk\bin;.
java.ext.dirs: C:\Program Files
(x86)\Java\jdk1.6.0_27\jre\lib\ext;C:\Windows\Sun\Java\lib\ext
os.name: Windows 7
os.arch: x86
os.version: 6.1
found:C:\Program Files (x86)\Java\jdk1.6.0_27\lib\tools.jar
found:C:\Program Files (x86)\Java\jdk1.6.0_27\lib\tools.jar


Cheers,

        Dave.

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Kermit Kiser
Sent: 22 September 2011 00:53
To: IBM Netrexx
Subject: [Ibm-netrexx] Call for help with tools.jar locater algorithm.

Per a recent discussion with Bill, locating tools.jar or the equivalent
classes.jar for Mac is a common problem to IDE setups as well as the
requested NetRexx installer. As a first step toward creating a suitable
algorithm usable by installers for locating the Java compiler, I have
drafted a small Java environment scanner that will report any possible
locations it finds.

If you have time, please run this scanner on any Java system you have
available and post the output back to the list. I am particularly
interested in Mac output since I have no access to such systems. Also
any JDK locations the program misses. This program does NOT require that
NetRexx be installed to run it - just download the binary file and start
it with "java envirotest". Here is the binary class file link and the
source is below that:

http://kenai.com/projects/netrexx-plus/downloads/download/Envirotest/envirot
est.class


(Please pardon the odd property and method names - I seem to have been
in a whimsical mood when I wrote it. )

-- Kermit

options binary
class envirotest
--                                        This program written by Kermit
Kiser on 2011/09/21 is placed in the public domain.

properties static

      java_version=String
      java_home=String
      java_class_path=String
      java_library_path=String
      java_ext_dirs=String
      os_name=String
      os_arch=String
      os_version=String

     f=System.getProperty('file.separator')
     s=System.getProperty('path.separator')

  method main(sa=String[]) static

      System.out.println("NetRexx Envirotest version 1.0")

      badabing

      badaboom

  method badabing static

      java_version=System.getProperty("java.version")
      System.out.println("java.version:" System.getProperty("java.version"))

     java_home= System.getProperty("java.home")
      System.out.println("java.home:" System.getProperty("java.home"))

      java_class_path= System.getProperty("java.class.path")
      System.out.println("java.class.path:"
System.getProperty("java.class.path"))

     java_library_path= System.getProperty("java.library.path")
      System.out.println("java.library.path:"
System.getProperty("java.library.path"))

     java_ext_dirs= System.getProperty("java.ext.dirs")
      System.out.println("java.ext.dirs:"
System.getProperty("java.ext.dirs"))

     os_name= System.getProperty("os.name")
      System.out.println("os.name:" System.getProperty("os.name"))

     os_arch= System.getProperty("os.arch")
      System.out.println("os.arch:" System.getProperty("os.arch"))

     os_version= System.getProperty("os.version")
      System.out.println("os.version:" System.getProperty("os.version"))

method badaboom static

     -- check java.home for a copy of tools.jar
     bondukey(java_home)

     --    and up one directory to look for jdk dirs
     phone_home=File(java_home).getParent
     bondukey(phone_home)
     conlist=File(phone_home).list
     loop i=0 for conlist.length
         tf=File(phone_home||f||conlist[i])
         if tf.isDirectory then bondukey(tf.getPath)
         end

     --    check if tools.jar has been added to an extension directory
     e=java_ext_dirs
     loop for 9
         p=e.indexOf(s)
         if p>=0 then do
             p1=e.substring(0,p)
             e=e.substring(p+1)
             flambam(p1||f"tools.jar")
             end
         else do
             flambam(e||f"tools.jar")
             leave
             end
         end

method flambam(burnbom=String) static

     if File(burnbom).exists then System.out.println("found:"burnbom)

method bondukey(durphon=String) static

     flambam(durphon||f"tools.jar")
     flambam(durphon||f"lib"f"tools.jar")
     flambam(durphon||f"lib"f"ext"f"tools.jar")
     flambam(durphon||f"bundle"f"Classes"f"classes.jar")
     flambam(durphon||f"Classes"f"classes.jar")
     flambam(durphon||f"classes.jar")

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Rony G. Flatscher (wu-wien)]

Hi there,

just a little idea: why not use the opensource janino package
<http://docs.codehaus.org/display/JANINO/Home>, which allows to compile
Java programs at runtime?

Reasoning: currently there is a dependency on the JDKs, which causes
sometimes problems, depending on platform and version. Also, NetRexx
deployments may cause a need on the client side to install the JDK,
which usually is a too much of a burden.

Using Janino instead, adds a different dependency, however Janino could
be distributed with NetRexx. It allows to totally forgo the
need/dependency on having a JDK installatiion. In its latest
incarnations it also serves as a bridge to the 1.6/6 compiler API. Or
with other words: Janino removes the dependency on tools.jar.

---rony

P.S.: Although not broadly known, BSF4ooRexx employs Janino for specific
use cases under the covers for quite a long time now with no problems
whatsoever.


_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Dave Woodman]

Looking at Janino, I am struck from by the point that it can compile code on
the fly in memory and then load and execute it in the same jvm.

A possible way to implement INTERPRET?

Dave.

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Rony G. Flatscher
Sent: 22 September 2011 09:35
To: IBM Netrexx
Subject: Janino to the rescue? (Re: [Ibm-netrexx] Call for help with
tools.jar locater algorithm.

Hi there,

just a little idea: why not use the opensource janino package
<http://docs.codehaus.org/display/JANINO/Home>, which allows to compile
Java programs at runtime?

Reasoning: currently there is a dependency on the JDKs, which causes
sometimes problems, depending on platform and version. Also, NetRexx
deployments may cause a need on the client side to install the JDK,
which usually is a too much of a burden.

Using Janino instead, adds a different dependency, however Janino could
be distributed with NetRexx. It allows to totally forgo the
need/dependency on having a JDK installatiion. In its latest
incarnations it also serves as a bridge to the 1.6/6 compiler API. Or
with other words: Janino removes the dependency on tools.jar.

---rony

P.S.: Although not broadly known, BSF4ooRexx employs Janino for specific
use cases under the covers for quite a long time now with no problems
whatsoever.


_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Kermit Kiser]

Bill -

I updated the scanner to better handle that private jre case - it now
scans the grandparent directory of java.home as well as the parent
directory.

http://kenai.com/projects/netrexx-plus/downloads/download/Envirotest/envirotest.class

Here is the output when I run it with the 1.7 jdk private jre on my Win7
system:

C:\Program Files\Java\jdk1.7.0\jre\bin>.\java envirotest
NetRexx Envirotest version 1.1
Java properties:
java.version: 1.7.0
java.home: C:\Program Files\Java\jdk1.7.0\jre
java.class.path: .
java.library.path: C:\Program
Files\Java\jdk1.7.0\jre\bin;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;C:\Windows\system32;C:\Windows;C:\Win
dows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\jEdit;c:\android\android-sdk-windows\tools;c:\ant\apache-ant-1.8.2\bin;c:\android\an
droid-sdk-windows\platform-tools;c:\netrexx;C:\Program
Files\Java\jdk1.6.0_20\bin;C:\GnuWin32\bin;.
java.ext.dirs: C:\Program
Files\Java\jdk1.7.0\jre\lib\ext;C:\Windows\Sun\Java\lib\ext
os.name: Windows 7
os.arch: amd64
os.version: 6.1
Checking java.home
Checking java.home parent
found:C:\Program Files\Java\jdk1.7.0\lib\tools.jar
Checking java.home grandparent
found:C:\Program Files\Java\jdk1.6.0_20\lib\tools.jar
found:C:\Program Files\Java\jdk1.6.0_27\lib\tools.jar
found:C:\Program Files\Java\jdk1.7.0\lib\tools.jar
found:C:\Program Files\Java\jre6\lib\ext\tools.jar
Checking Java extension directories


Here is the updated source code:

options binary
class envirotest
-- This program written by Kermit Kiser on 2011/09/21 is placed in the
public domain.

properties static

java_version=String
java_home=String
java_class_path=String
java_library_path=String
java_ext_dirs=String
os_name=String
os_arch=String
os_version=String

f=System.getProperty('file.separator')
s=System.getProperty('path.separator')

method main(sa=String[]) static

System.out.println("NetRexx Envirotest version 1.1")

badabing

badaboom

method badabing static

System.out.println("Java properties:")

java_version=System.getProperty("java.version")
System.out.println("java.version:" System.getProperty("java.version"))

java_home= System.getProperty("java.home")
System.out.println("java.home:" System.getProperty("java.home"))

java_class_path= System.getProperty("java.class.path")
System.out.println("java.class.path:" System.getProperty("java.class.path"))

java_library_path= System.getProperty("java.library.path")
System.out.println("java.library.path:"
System.getProperty("java.library.path"))

java_ext_dirs= System.getProperty("java.ext.dirs")
System.out.println("java.ext.dirs:" System.getProperty("java.ext.dirs"))

os_name= System.getProperty("os.name")
System.out.println("os.name:" System.getProperty("os.name"))

os_arch= System.getProperty("os.arch")
System.out.println("os.arch:" System.getProperty("os.arch"))

os_version= System.getProperty("os.version")
System.out.println("os.version:" System.getProperty("os.version"))

method badaboom static

System.out.println("Checking java.home")
-- check java.home for a copy of tools.jar
bondukey(java_home)

System.out.println("Checking java.home parent")
-- and up one directory to look for jdk dirs
phone_home=File(java_home).getParent
scandirs(phone_home)

System.out.println("Checking java.home grandparent")
grand_home=File(phone_home).getParent
if grand_home\=null then do
scandirs(grand_home)
end

System.out.println("Checking Java extension directories")
-- check if tools.jar has been added to an extension directory
e=java_ext_dirs
loop for 9
p=e.indexOf(s)
if p>=0 then do
p1=e.substring(0,p)
e=e.substring(p+1)
flambam(p1||f"tools.jar")
end
else do
flambam(e||f"tools.jar")
leave
end
end

method scandirs(base=String) static
conlist=File(base).list
loop i=0 for conlist.length
tf=File(base||f||conlist[i])
if tf.isDirectory then bondukey(tf.getPath)
end

method flambam(burnbom=String) static

if File(burnbom).exists then System.out.println("found:"burnbom)

method bondukey(durphon=String) static

flambam(durphon||f"tools.jar")
flambam(durphon||f"lib"f"tools.jar")
flambam(durphon||f"lib"f"ext"f"tools.jar")
flambam(durphon||f"bundle"f"Classes"f"classes.jar")
flambam(durphon||f"Classes"f"classes.jar")
flambam(durphon||f"classes.jar")


On 9/21/2011 5:37 PM, [hidden email] wrote:

> Kermit,
> I've run your program in the Eclipse environment in both the production and
> development (debug) versions.  Here are the results - almost identical as
> might be expected.
>
> NetRexx portable processor, version NetRexx 3.01RC1, build 40-20110905-2355
> Copyright (c) RexxLA, 2011.  All rights reserved.
> Parts Copyright (c) IBM Corporation, 1995,2008.
> Program envirotest.nrx
>    === class envirotest ===
>      function main(String[])
>      function badabing
>      function badaboom
>      function flambam(String)
>      function bondukey(String)
> ===== Exec: envirotest =====
> NetRexx Envirotest version 1.0
> java.version: 1.6.0_27
> java.home: C:\Program Files\Java\jdk1.6.0_27\jre
> java.class.path: F:\EclipseNetRexx\E 3.6.2
> Test\eclipse\configuration\org.eclipse.osgi\bundles\4\1\.cp\jars\NetRexxC.ja
> r
> java.library.path: C:\Program
> Files\Java\jdk1.6.0_27\bin;C:\WINDOWS\Sun\Java\bin;C:\WINDOWS\system32;C:\WI
> NDOWS;C:/Program Files/Java/jre6/bin/client;C:/Program
> Files/Java/jre6/bin;C:/Program
> Files/Java/jre6/lib/i386;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\
> Wbem;C:\WINDOWS\system32\WindowsPowerShell\v1.0;C:\WINDOWS\system32\WindowsP
> owerShell\v1.0;C:\cygwin\bin;F:\EclipseNetRexx\E 3.6.2 Test\eclipse;;.
> java.ext.dirs: C:\Program
> Files\Java\jdk1.6.0_27\jre\lib\ext;C:\WINDOWS\Sun\Java\lib\ext
> os.name: Windows XP
> os.arch: x86
> os.version: 5.1
> found:C:\Program Files\Java\jdk1.6.0_27\lib\tools.jar
> found:C:\Program Files\Java\jdk1.6.0_27\lib\tools.jar
> Processing of 'envirotest.nrx' complete
>
> ----------------------------------------------------------------
> NetRexx portable processor, version NetRexx 3.01RC1, build 40-20110905-2355
> Copyright (c) RexxLA, 2011.  All rights reserved.
> Parts Copyright (c) IBM Corporation, 1995,2008.
> Program envirotest.nrx
>    === class envirotest ===
>      function main(String[])
>      function badabing
>      function badaboom
>      function flambam(String)
>      function bondukey(String)
> ===== Exec: envirotest =====
> NetRexx Envirotest version 1.0
> java.version: 1.6.0_27
> java.home: C:\Program Files\Java\jdk1.6.0_27\jre
> java.class.path: F:\EclipseNetRexx\E 3.6.2
> NetRexx\workspace\eclipsenetrexx\jars\NetRexxC.jar
> java.library.path: C:\Program
> Files\Java\jdk1.6.0_27\bin;C:\WINDOWS\Sun\Java\bin;C:\WINDOWS\system32;C:\WI
> NDOWS;C:\Program Files\Java\jdk1.6.0_27\jre\bin;C:/Program
> Files/Java/jre6/bin/client;C:/Program Files/Java/jre6/bin;C:/Program
> Files/Java/jre6/lib/i386;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\
> Wbem;C:\WINDOWS\system32\WindowsPowerShell\v1.0;C:\WINDOWS\system32\WindowsP
> owerShell\v1.0;C:\cygwin\bin;F:\EclipseNetRexx\E 3.6.2 NetRexx\eclipse;;.
> java.ext.dirs: C:\Program
> Files\Java\jdk1.6.0_27\jre\lib\ext;C:\WINDOWS\Sun\Java\lib\ext
> os.name: Windows XP
> os.arch: x86
> os.version: 5.1
> found:C:\Program Files\Java\jdk1.6.0_27\lib\tools.jar
> found:C:\Program Files\Java\jdk1.6.0_27\lib\tools.jar
> Processing of 'envirotest.nrx' complete
>
> --------------------------------------------------------------
>
> Perhaps Rene will comment regarding the Mac - he uses one.
>
> To handle this problem in the Eclipse plugin, I provide a user settable
> compiler classpath option.  To set the default, I try to guess the location
> by taking assuming that the JDK JRE has been specified in JAVA_HOME or
> java.home, and replacing "\jre" with "\lib\tools.jar".  That sort of works
> for windows - on the Mac (based on what Rene told me), no compiler
> classpath is necessary.  I don't know about *nix systems.  Allowing the
> user to set the compiler classpath directly mostly solves the problem for
> the Eclipse situation, and I agree it is better if it can be done
> automatically.
>
> --------------------------------------------------------------------
> mail2web.com – What can On Demand Business Solutions do for you?
> http://link.mail2web.com/Business/SharePoint
>
>
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>
>
>

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[christel.u.w.pachl christel.u.w.pachl]

I think this was what the Rexx compiler on VM and MVS did and does for Interpret :-)
Greetings from Vienna (2 blocks from Rony's office)
Walter
---- Dave Woodman <[hidden email]> schrieb:

> Looking at Janino, I am struck from by the point that it can compile code on
> the fly in memory and then load and execute it in the same jvm.
>
> A possible way to implement INTERPRET?
>
> Dave.
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Rony G. Flatscher
> Sent: 22 September 2011 09:35
> To: IBM Netrexx
> Subject: Janino to the rescue? (Re: [Ibm-netrexx] Call for help with
> tools.jar locater algorithm.
>
> Hi there,
>
> just a little idea: why not use the opensource janino package
> <http://docs.codehaus.org/display/JANINO/Home>, which allows to compile
> Java programs at runtime?
>
> Reasoning: currently there is a dependency on the JDKs, which causes
> sometimes problems, depending on platform and version. Also, NetRexx
> deployments may cause a need on the client side to install the JDK,
> which usually is a too much of a burden.
>
> Using Janino instead, adds a different dependency, however Janino could
> be distributed with NetRexx. It allows to totally forgo the
> need/dependency on having a JDK installatiion. In its latest
> incarnations it also serves as a bridge to the 1.6/6 compiler API. Or
> with other words: Janino removes the dependency on tools.jar.
>
> ---rony
>
> P.S.: Although not broadly known, BSF4ooRexx employs Janino for specific
> use cases under the covers for quite a long time now with no problems
> whatsoever.
>
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Kermit Kiser]

Dave -

Are you talking about the classic Rexx INTERPRET statement? Implementing
that might cause some problems with scope/context in an object environment.

NetRexx itself does not use a compiler when interpreting code, so Janino
probably does not apply there.

@ Rony -

We have been debating the Janino compiler issue and are hesitant to
offer it because it does not seem to be maintained very much currently -
it claims to support Java 1.4 while we have targeted Java 1.5 for
NetRexx support.

-- Kermit

On 9/22/2011 2:11 AM, Dave Woodman wrote:

> Looking at Janino, I am struck from by the point that it can compile code on
> the fly in memory and then load and execute it in the same jvm.
>
> A possible way to implement INTERPRET?
>
> Dave.
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Rony G. Flatscher
> Sent: 22 September 2011 09:35
> To: IBM Netrexx
> Subject: Janino to the rescue? (Re: [Ibm-netrexx] Call for help with
> tools.jar locater algorithm.
>
> Hi there,
>
> just a little idea: why not use the opensource janino package
> <http://docs.codehaus.org/display/JANINO/Home>, which allows to compile
> Java programs at runtime?
>
> Reasoning: currently there is a dependency on the JDKs, which causes
> sometimes problems, depending on platform and version. Also, NetRexx
> deployments may cause a need on the client side to install the JDK,
> which usually is a too much of a burden.
>
> Using Janino instead, adds a different dependency, however Janino could
> be distributed with NetRexx. It allows to totally forgo the
> need/dependency on having a JDK installatiion. In its latest
> incarnations it also serves as a bridge to the 1.6/6 compiler API. Or
> with other words: Janino removes the dependency on tools.jar.
>
> ---rony
>
> P.S.: Although not broadly known, BSF4ooRexx employs Janino for specific
> use cases under the covers for quite a long time now with no problems
> whatsoever.
>
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>
>
>

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[billfen]

Being able to interface with different Java compilers is of course useful.
Once NetRexx adopts the standard API, it will be able to use any compiler
that uses it (and supports the Java that NetRexx generates).

A quick look at Janino showed a list of unsupported Java features -
possibly a problem?  I would assume that installing Janino is no less
complicated than installing the JDK (its either janino.jar or tools.jar).
I don't see a real advantage in that regard.  On the other hand, Janino has
some useful features and giving NetRexx the ability to use it is advisable.

I put a compiler path option into the Eclipse plugin so that any compiler
can be used as long as the API matches or can be made to match with some
kind of interface.  I think it is better to give the user the ability to
choose his compiler rather than distributing one, but YMMV.

It seems to me that we should concentrate on adding a simple compiler
option to NetRexx which says "Use the standard compiler API, not the
internal Sun interface".

Bill

On 9/22/2011 4:34 AM, Rony G. Flatscher wrote:

> Hi there,
>
> just a little idea: why not use the opensource janino package
> <http://docs.codehaus.org/display/JANINO/Home>, which allows to compile
> Java programs at runtime?
>
> Reasoning: currently there is a dependency on the JDKs, which causes
> sometimes problems, depending on platform and version. Also, NetRexx
> deployments may cause a need on the client side to install the JDK,
> which usually is a too much of a burden.
>
> Using Janino instead, adds a different dependency, however Janino could
> be distributed with NetRexx. It allows to totally forgo the
> need/dependency on having a JDK installatiion. In its latest
> incarnations it also serves as a bridge to the 1.6/6 compiler API. Or
> with other words: Janino removes the dependency on tools.jar.
>
> ---rony
>
> P.S.: Although not broadly known, BSF4ooRexx employs Janino for specific
> use cases under the covers for quite a long time now with no problems
> whatsoever.
>
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

--------------------------------------------------------------------
mail2web.com – Enhanced email for the mobile individual based on Microsoft®
Exchange - http://link.mail2web.com/Personal/EnhancedEmail



_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Dave Woodman]

The classic Rexx INTERPRET was, indeed, the lines along which I was
thinking.

If it won't fly, it won't fly!

        Dave.

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Kermit Kiser
Sent: 22 September 2011 10:35
To: IBM Netrexx
Subject: Re: Janino to the rescue? (Re: [Ibm-netrexx] Call for help with
tools.jar locater algorithm.

Dave -

Are you talking about the classic Rexx INTERPRET statement? Implementing
that might cause some problems with scope/context in an object environment.

NetRexx itself does not use a compiler when interpreting code, so Janino
probably does not apply there.

@ Rony -

We have been debating the Janino compiler issue and are hesitant to
offer it because it does not seem to be maintained very much currently -
it claims to support Java 1.4 while we have targeted Java 1.5 for
NetRexx support.

-- Kermit

On 9/22/2011 2:11 AM, Dave Woodman wrote:
> Looking at Janino, I am struck from by the point that it can compile code
on
> the fly in memory and then load and execute it in the same jvm.
>
> A possible way to implement INTERPRET?
>
> Dave.
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Rony G.
Flatscher

> Sent: 22 September 2011 09:35
> To: IBM Netrexx
> Subject: Janino to the rescue? (Re: [Ibm-netrexx] Call for help with
> tools.jar locater algorithm.
>
> Hi there,
>
> just a little idea: why not use the opensource janino package
> <http://docs.codehaus.org/display/JANINO/Home>, which allows to compile
> Java programs at runtime?
>
> Reasoning: currently there is a dependency on the JDKs, which causes
> sometimes problems, depending on platform and version. Also, NetRexx
> deployments may cause a need on the client side to install the JDK,
> which usually is a too much of a burden.
>
> Using Janino instead, adds a different dependency, however Janino could
> be distributed with NetRexx. It allows to totally forgo the
> need/dependency on having a JDK installatiion. In its latest
> incarnations it also serves as a bridge to the 1.6/6 compiler API. Or
> with other words: Janino removes the dependency on tools.jar.
>
> ---rony
>
> P.S.: Although not broadly known, BSF4ooRexx employs Janino for specific
> use cases under the covers for quite a long time now with no problems
> whatsoever.
>
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>
>
>

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Rony G. Flatscher (wu-wien)]

>
> We have been debating the Janino compiler issue and are hesitant to
> offer it because it does not seem to be maintained very much currently
> - it claims to support Java 1.4 while we have targeted Java 1.5 for
> NetRexx support.
Janino has become stable, so no need to keep developing it. The question
is whether maintenance is available, if need arises. While incorporating
Janino into BSF4ooRexx I stumbled over a bug which the author of Janino
fixed within a few days, quite impressive response time.

One does not necessarily need 1.5 Java support, even if you supported
some 1.5 Java features like generics in NetRexx. Whether moving the
baseline from to 1.5 or not is more a question of the byte code version
NetRexx should create. In that case I would suggest to keep it as low as
possible unless very good reasons can be put forward to want to supply
newer byte code versions (like invoke dynamic, but then the baseline
would have to be raised to 1.7/7).

If you follow the presented link you see however, that Janino will allow
to exploit the 1.6/6 compiler. (The Apache solution pointed to from the
Janino homepage is even able to serve more compilers transparently.)

---rony

> On 9/22/2011 2:11 AM, Dave Woodman wrote:
>> Looking at Janino, I am struck from by the point that it can compile
>> code on
>> the fly in memory and then load and execute it in the same jvm.
>>
>> A possible way to implement INTERPRET?
>>
>> Dave.
>>
>> -----Original Message-----
>> From: [hidden email]
>> [mailto:[hidden email]] On Behalf Of Rony G.
>> Flatscher
>> Sent: 22 September 2011 09:35
>> To: IBM Netrexx
>> Subject: Janino to the rescue? (Re: [Ibm-netrexx] Call for help with
>> tools.jar locater algorithm.
>>
>> Hi there,
>>
>> just a little idea: why not use the opensource janino package
>> <http://docs.codehaus.org/display/JANINO/Home>, which allows to compile
>> Java programs at runtime?
>>
>> Reasoning: currently there is a dependency on the JDKs, which causes
>> sometimes problems, depending on platform and version. Also, NetRexx
>> deployments may cause a need on the client side to install the JDK,
>> which usually is a too much of a burden.
>>
>> Using Janino instead, adds a different dependency, however Janino could
>> be distributed with NetRexx. It allows to totally forgo the
>> need/dependency on having a JDK installatiion. In its latest
>> incarnations it also serves as a bridge to the 1.6/6 compiler API. Or
>> with other words: Janino removes the dependency on tools.jar.
>>
>> ---rony
>>
>> P.S.: Although not broadly known, BSF4ooRexx employs Janino for specific
>> use cases under the covers for quite a long time now with no problems
>> whatsoever.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Rony G. Flatscher (wu-wien)]

On 22.09.2011 11:46, [hidden email] wrote:
> Being able to interface with different Java compilers is of course useful.
> Once NetRexx adopts the standard API, it will be able to use any compiler
> that uses it (and supports the Java that NetRexx generates).
>  
The problem seems to be that before 1.6/6 there is no standard compiler
installed with Java. Hence the need to locate, get and install the JDK
or any other Java compiler in order for NetRexx to be even able to compile.

Finding, installing and configuring the compiler is easy for guys like
you and me who have no problems locating, installing and configuring it.

It has turned into a hell for many others, who have had no prior
exposure to Java. We have been witnessing this problem quite a few times
by following the postings of newcomers and learning about the problems
they face. (Some of these problems would never surface for Java-savvy
people, because they know which paths are fruitless to take. Yet, for a
human-oriented philosophy NetRexx should me made as easy to use as
possible and not having the users to hunt down for fulfilling
dependencies, which nowadays could be incorporated into the NetRexx
distribution, thereby adding a big chunk of relief.)

Even, if a NetRexx developer can be expected to eventually locate and
develop the necessary knowledge to install and configure a Java compiler
this may pose a rather big problem if thinking about deploying NetRexx
applications in the field that need for one reason or another the
ability to e.g. compile NetRexx programs. For these use-cases having a
compiler on board of the NetRexx distribution would solve the problem.
This would also solve the problem for NetRexx developers who have been
exposed to Rexx, but not necessarily to Java development.


---rony

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Mike Cowlishaw]

 
Haven't looked at the code for a decade, of course .. but the general intent was
that NetRexxC could be tweaked quite easily to emit bytecodes instead of (or in
addition to) Java code or interpretation/execution.  That would sidestep the
need for a Java compiler completely (although one would want to keep
testing/using that path in development).

IIRC each clause-handler has a generate [java] and an interpret method, and one
could just add an emitbytecode method to them all (for example).  Plus something
that collects and wraps the bytecodes emitted (and later perhaps could apply
some optimizations -- although the JITs do that pretty well).


Mike

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[David Requena]

There are 3 different "Java" levels we need to consider here:

- Level needed to actually run the NetRexx Translator, affecting which environments can be used for NetRexx development.

- Level of the translated intermediate java code, affecting which Java compilers can be used to emit byte-code as a second step.

- Level of final byte-code, affecting which runtime environments are supported for NetRexx programs (also influenced by the level to which the runtime itself was compiled)

It is unclear to me to what are we referring when we say "we have targeted Java 1.5 for NetRexx support".

Is it about point one above? Point two? Both?

2011/9/22 Rony G. Flatscher <[hidden email]>

On 22.09.2011 11:46, [hidden email] wrote:
> Being able to interface with different Java compilers is of course useful.
> Once NetRexx adopts the standard API, it will be able to use any compiler
> that uses it (and supports the Java that NetRexx generates).
>

The problem seems to be that before 1.6/6 there is no standard compiler
installed with Java. Hence the need to locate, get and install the JDK
or any other Java compiler in order for NetRexx to be even able to compile.

Finding, installing and configuring the compiler is easy for guys like
you and me who have no problems locating, installing and configuring it.

It has turned into a hell for many others, who have had no prior
exposure to Java. We have been witnessing this problem quite a few times
by following the postings of newcomers and learning about the problems
they face. (Some of these problems would never surface for Java-savvy
people, because they know which paths are fruitless to take. Yet, for a
human-oriented philosophy NetRexx should me made as easy to use as
possible and not having the users to hunt down for fulfilling
dependencies, which nowadays could be incorporated into the NetRexx
distribution, thereby adding a big chunk of relief.)

Even, if a NetRexx developer can be expected to eventually locate and
develop the necessary knowledge to install and configure a Java compiler
this may pose a rather big problem if thinking about deploying NetRexx
applications in the field that need for one reason or another the
ability to e.g. compile NetRexx programs. For these use-cases having a
compiler on board of the NetRexx distribution would solve the problem.
This would also solve the problem for NetRexx developers who have been
exposed to Rexx, but not necessarily to Java development.


---rony

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

--
Saludos / Regards,
David Requena

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Tom Maynard]

On 9/22/2011 4:16 AM, Kermit Kiser wrote:

I updated the scanner to better handle that private jre case - it now scans the grandparent directory of java.home as well as the parent directory.

It's not really a fair test since I'm preparing to migrate to a new laptop (and deleted a ton of stuff yesterday -- but not Java), but here's the result from this box (run from the root directory), on Win XP SP3:

C:\>dir en*
 Volume in drive C has no label.
 Volume Serial Number is 0867-4495

 Directory of C:\

09/22/2011  09:13 AM             3,409 envirotest.class
               1 File(s)          3,409 bytes
               0 Dir(s)  35,566,301,184 bytes free

C:\>java envirotest
NetRexx Envirotest version 1.1
Java properties:
java.version: 1.6.0_18
java.home: C:\Program Files\Java\jdk1.6.0_18\jre
java.class.path: .;C:\classes\miglayout.jar;C:\classes\groovy-all.jar;C:\classes
\groovypp-all.jar;C:\Program Files\Java\jdk1.6.0_18\lib\tools.jar;C:\Program Fil
es\Java\jre6\lib\ext\QTJava.zip
java.library.path: C:\Program Files\Java\jdk1.6.0_18\bin;.;C:\WINDOWS\Sun\Java\b
in;C:\WINDOWS\system32;C:\WINDOWS;c:\groovy\bin;C:\griffon\bin;c:\grails\bin;c:\
bin;c:\tsepro;c:\program files\vim\vim72;c:\cygwin\bin;C:\Program Files\Java\jdk
1.6.0_18\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program
Files\Support Tools\;C:\PROGRA~1\DISKEE~1\DISKEE~1\;C:\WINDOWS\system32\WindowsP
owerShell\v1.0;C:\Program Files\QuickTime\QTSystem\;C:\Program Files\Tangbu\XWin
g
java.ext.dirs: C:\Program Files\Java\jdk1.6.0_18\jre\lib\ext;C:\WINDOWS\Sun\Java
\lib\ext
os.name: Windows XP
os.arch: x86
os.version: 5.1
Checking java.home
found:C:\Program Files\Java\jdk1.6.0_18\jre\lib\ext\tools.jar
Checking java.home parent
found:C:\Program Files\Java\jdk1.6.0_18\jre\lib\ext\tools.jar
found:C:\Program Files\Java\jdk1.6.0_18\lib\tools.jar
Checking java.home grandparent
found:C:\Program Files\Java\jdk1.6.0_18\lib\tools.jar
found:C:\Program Files\Java\jre6\lib\ext\tools.jar
Checking Java extension directories
found:C:\Program Files\Java\jdk1.6.0_18\jre\lib\ext\tools.jar

C:\>

The output is rather interesting to me -- in a "none of your business" kind of way -- showing as it does what my priorities are (or at least my priorities "du jour").  Or at least a Java-centric none of your business view into my little world.  I feel like I need to change into clean underwear now -- or should have done before I ran that thing. <BFG>

Also of note: my NetRexx installation was done during the heydey years ... when copying tools.jar willy-nilly was de rigueur.  I'd forgotten about that!  That sin will not be committed again on the new destination (I hope).  [But other sins will, I'm sure.]

Anyway, now that I've had my shower I can say it was rather fun ... in a none-of-your-business kind of way, of course.

Tom.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Tom Maynard]

On 9/22/2011 5:24 AM, Rony G. Flatscher wrote:
> Finding, installing and configuring the compiler is easy for guys like
> you and me who have no problems locating, installing and configuring it.

Ahem.  I have to take issue with this (at least partially).  I've been
working (fighting?) with Java since its 1.0 days, and installing NetRexx
each and every time I did was a near nightmare.  Put tools.jar where?  
Adjust the classpath how?  I shudder even now as I remember the struggle.

I would put the priority of a NetRexx installer right at the top of the
list -- such a high priority that ... <gulp> ... I'm volunteering to
work on the project myself!  Give me the requirements list (at least for
Windows now) and I'll have a whack at it.  I'm getting ready to migrate
to a brand new machine and installing Java/NetRexx is right at the top
of my list.


> deploying NetRexx
> applications in the field

This topic has come up before (several times), and the OneJar (or
similar) approach seems to be a workable solution ... given some work to
tailor it suitably for NetRexx.

Tom.
_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Bruce Skelly]

Hi Kermit,

I downloaded your class file, and ran it on my Mac OS X (Snow Leopard) system.  

At the command prompt I got this:

[hidden email] /Users/bjskelly/Downloads> java ./envirotest.class
Exception in thread "main" java.lang.NoClassDefFoundError: //envirotest/class
Caused by: java.lang.ClassNotFoundException: ..envirotest.class
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
[hidden email] /Users/bjskelly/Downloads> 

Then using jbd, I got this result.

[hidden email] /Users/bjskelly/Downloads> jdb ./envirotest.class

Initializing jdb ...
> run envirotest
run  envirotest
Set uncaught java.lang.Throwable
Set deferred uncaught java.lang.Throwable
> 
VM Started: NetRexx Envirotest version 1.1
Java properties:
java.version: 1.6.0_26
java.home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
java.class.path: .
java.library.path: .:/Users/bjskelly/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java
java.ext.dirs: /Users/bjskelly/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/ext
os.name: Mac OS X
os.arch: x86_64
os.version: 10.6.8
Checking java.home
found:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/bundle/Classes/classes.jar
Checking java.home parent
found:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/classes.jar
found:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/bundle/Classes/classes.jar
Checking java.home grandparent
found:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/classes.jar
Checking Java extension directories

The application exited

On Sep 21, 2011, at 10:57 PM, [hidden email] wrote:

From: Kermit Kiser <[hidden email]>

Date: September 21, 2011 4:53:07 PM PDT

To: IBM Netrexx <[hidden email]>

Subject: [Ibm-netrexx] Call for help with tools.jar locater algorithm.

Reply-To: IBM Netrexx <[hidden email]>

Per a recent discussion with Bill, locating tools.jar or the equivalent classes.jar for Mac is a common problem to IDE setups as well as the requested NetRexx installer. As a first step toward creating a suitable algorithm usable by installers for locating the Java compiler, I have drafted a small Java environment scanner that will report any possible locations it finds.

If you have time, please run this scanner on any Java system you have available and post the output back to the list. I am particularly interested in Mac output since I have no access to such systems. Also any JDK locations the program misses. This program does NOT require that NetRexx be installed to run it - just download the binary file and start it with "java envirotest". Here is the binary class file link and the source is below that:

http://kenai.com/projects/netrexx-plus/downloads/download/Envirotest/envirotest.class

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[alansam]

On 22 September 2011 08:31, Bruce Skelly <[hidden email]> wrote:

Hi Kermit,

I downloaded your class file, and ran it on my Mac OS X (Snow Leopard) system.  

At the command prompt I got this:

[hidden email] /Users/bjskelly/Downloads> java ./envirotest.class
Exception in thread "main" java.lang.NoClassDefFoundError: //envirotest/class
Caused by: java.lang.ClassNotFoundException: ..envirotest.class

Try:

java envirotest

Yo confused Java by asking for ./envirotest.class.  It's looking for a class file called envirotest/class.class which obviously isn't there.  The ./ prefix doesn't make life any easier either.

Alan.

--
Can't tweet, won't tweet!

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[ThSITC]

Kermit,
    regarding possible implementation of INTERPRET:

I do personally use a new OPTION SYMBOLIC in my own translator which
DOES capture the current Environment etc and then uses the the value and
system Functions to obtain the values.

The source is already in

org.netrexx.thsitc.runtime.compatibilty

Module: RexxSymb.nrx

It would, however, require to modify RxTranslator to emit the proper
StartEnv (Start Environment) and EndEnv (End Environment) calls.

But this technique WILL allow INTERPRET in NetRexx, especially when
Janino is used, as Rony suggests.

Greetings,
Thomas.
=======================================================
Am 22.09.2011 11:34, schrieb Kermit Kiser:

> Dave -
>
> Are you talking about the classic Rexx INTERPRET statement?
> Implementing that might cause some problems with scope/context in an
> object environment.
>
> NetRexx itself does not use a compiler when interpreting code, so
> Janino probably does not apply there.
>
> @ Rony -
>
> We have been debating the Janino compiler issue and are hesitant to
> offer it because it does not seem to be maintained very much currently
> - it claims to support Java 1.4 while we have targeted Java 1.5 for
> NetRexx support.
>
> -- Kermit
>
> On 9/22/2011 2:11 AM, Dave Woodman wrote:
>> Looking at Janino, I am struck from by the point that it can compile
>> code on
>> the fly in memory and then load and execute it in the same jvm.
>>
>> A possible way to implement INTERPRET?
>>
>> Dave.
>>
>> -----Original Message-----
>> From: [hidden email]
>> [mailto:[hidden email]] On Behalf Of Rony G.
>> Flatscher
>> Sent: 22 September 2011 09:35
>> To: IBM Netrexx
>> Subject: Janino to the rescue? (Re: [Ibm-netrexx] Call for help with
>> tools.jar locater algorithm.
>>
>> Hi there,
>>
>> just a little idea: why not use the opensource janino package
>> <http://docs.codehaus.org/display/JANINO/Home>, which allows to compile
>> Java programs at runtime?
>>
>> Reasoning: currently there is a dependency on the JDKs, which causes
>> sometimes problems, depending on platform and version. Also, NetRexx
>> deployments may cause a need on the client side to install the JDK,
>> which usually is a too much of a burden.
>>
>> Using Janino instead, adds a different dependency, however Janino could
>> be distributed with NetRexx. It allows to totally forgo the
>> need/dependency on having a JDK installatiion. In its latest
>> incarnations it also serves as a bridge to the 1.6/6 compiler API. Or
>> with other words: Janino removes the dependency on tools.jar.
>>
>> ---rony
>>
>> P.S.: Although not broadly known, BSF4ooRexx employs Janino for specific
>> use cases under the covers for quite a long time now with no problems
>> whatsoever.
>>
>>
>> _______________________________________________
>> Ibm-netrexx mailing list
>> [hidden email]
>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>>
>> _______________________________________________
>> Ibm-netrexx mailing list
>> [hidden email]
>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>>
>>
>>
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>
>

--
Thomas Schneider (Founder of www.thsitc.com) Member of the Rexx Languge
Asscociation (www.rexxla.org) Member of the NetRexx Developer's Team
(www.netrexx.org)
_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Kermit Kiser]

Actually the requirement for Java 1.5 was technically only to build the NetRexx translator itself so that the developers could know what features were available to code changes with.

I think we also assumed that it would apply to the runtime environment for NetRexx so that we could be sure that any changes that passed through to the Java code would work and that we did not need to test everything with every old version of Java. In reality, I don't think any of the new features require more than Java 1.4 at this point and code that does not use any new features would probably still compile and run with even older versions of Java. Testing that would be a nightmare I think and looking toward future enhancement we definitely need a specific target that we can require and test with. I would have preferred Java 1.6 as it has been released and open source for 5 years now and includes the compiler API and JSR223, but 1.5 was the compromise reached by René after taking into account the fact that legacy code could still run with NetRexx 3.00 if it needed an older Java environment.

As far as allowing NetRexx to create byte-code without the presence of a Java compiler, I agree with Mike. If possible, it would be far better to give NetRexx the option to produce the byte-code directly than to depend on something like Janino for which we do not control the code! I have no idea how difficult that would be since I have not studied byte-code at all but Mike seems to think it would not be too difficult. Has anyone looked into that yet?

-- Kermit


On 9/22/2011 6:26 AM, David Requena wrote:

There are 3 different "Java" levels we need to consider here:

- Level needed to actually run the NetRexx Translator, affecting which environments can be used for NetRexx development.

- Level of the translated intermediate java code, affecting which Java compilers can be used to emit byte-code as a second step.

- Level of final byte-code, affecting which runtime environments are supported for NetRexx programs (also influenced by the level to which the runtime itself was compiled)

It is unclear to me to what are we referring when we say "we have targeted Java 1.5 for NetRexx support".

Is it about point one above? Point two? Both?

2011/9/22 Rony G. Flatscher <[hidden email]>

On 22.09.2011 11:46, [hidden email] wrote:
> Being able to interface with different Java compilers is of course useful.
> Once NetRexx adopts the standard API, it will be able to use any compiler
> that uses it (and supports the Java that NetRexx generates).
>

The problem seems to be that before 1.6/6 there is no standard compiler
installed with Java. Hence the need to locate, get and install the JDK
or any other Java compiler in order for NetRexx to be even able to compile.

Finding, installing and configuring the compiler is easy for guys like
you and me who have no problems locating, installing and configuring it.

It has turned into a hell for many others, who have had no prior
exposure to Java. We have been witnessing this problem quite a few times
by following the postings of newcomers and learning about the problems
they face. (Some of these problems would never surface for Java-savvy
people, because they know which paths are fruitless to take. Yet, for a
human-oriented philosophy NetRexx should me made as easy to use as
possible and not having the users to hunt down for fulfilling
dependencies, which nowadays could be incorporated into the NetRexx
distribution, thereby adding a big chunk of relief.)

Even, if a NetRexx developer can be expected to eventually locate and
develop the necessary knowledge to install and configure a Java compiler
this may pose a rather big problem if thinking about deploying NetRexx
applications in the field that need for one reason or another the
ability to e.g. compile NetRexx programs. For these use-cases having a
compiler on board of the NetRexx distribution would solve the problem.
This would also solve the problem for NetRexx developers who have been
exposed to Rexx, but not necessarily to Java development.


---rony

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

--
Saludos / Regards,
David Requena

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/