Design for compiler independence of the NetRexx translator

[rvjansen]

Please shoot:

Design for compiler independence of the NetRexx translator

Rationale

For several reasons one would want to exchange the compiler that is called by the NetRexx translator for the purpose of AOT (ahead-of-time) compiling.

Some of these are:

1) no Java SDK present but JRE present on customer systems (the majority of cases in my reality)
2) exotic platforms where SDK is installed but compiler class hard to find
3) (potential) bug in compiler version that is available
4) first install for new and interested users fails on compiler class not found on classpath; user loses interest

Solution Make an environment variable available on platforms that support it that enables the code in RxTranslator to find an alternative compiler class on the classpath.

This environment variable takes the form of:

nrx.compiler=x

where the default call would be System.getProperty("nrx.compiler","javac"), i.e. when the property is not found, the translator defaults to the compiler that is also called by javac.

Values of x can initially be javac or ecj.

ecj is the eclipse batch compiler. An installer could do a testrun of a compile using javac and fall back to ecj if it encounters the exception that indicates it is not found on the classpath. This implies we have to deliver ecj.jar (this is how I call it for short, it has a long and unfriendly name containing release info). We control the placement of this jar in the installer, and will place it next to NetRexxC.jar. When the testrun does not find it, the installer can suggest to set the variable or do that itself.

Consequences The call to the compiler class needs to use reflective loading because otherwise there will be a linking dependency introduced to it. Javac ("sun.tools.javac") was never reflectively loaded because it was assumed that it was there, due to the requirements for the translator package. However, this will make compiling the translator fail on the aforementioned systems.

(Note that it is still possible to generate java source for the compiler on another system, and compile this in a standalone run on a system that has the eclipse compiler but not the SDK - this was recently verified. This is possible because no NetRexx runtime class is used in the translator. This has as a consequence that either '==' or '.equals' must be used in the implementation - the normal equality operator '=' implies decimal.)

When called by the translator, decisions must be taken what to do with the output. This also in the light of the 'lint'-like capabilities of the Eclipse compiler, which is not unlike the older Jikes tool.

It must be positively verified that the interpreter works (c.q. keeps working) when compiling is not possible.

Alternatives

Alternatively, the whole line of compiler invocation to be executed could be specified. I am proponent of releasing a limited set of possibilities, with compilers that we have verified to work, which at this point are javac and ecj. The true tinkerer can solve this problem him/herself probably using the source code if so required.

Please let me know what you think. I will proceed to enter the design into a support issue, and schedule its implementation when there is sufficient support.

best regards,

René Jansen.

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

[billfen]

My initial reaction is that environment variables should be avoided.

Wasn't this discussed some time ago?  I'll have to go back and check,
but as I recall the issue of simply using the standard compiler
interface required dropping support of Java 1.4.

Considering the state of Java development, I would think that requiring
Java 1.5 is reasonable at this point.  Wouldn't using the standard
compiler interface (perhaps controlled by an option)  solve this?

Bill



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

[Jerry McBride]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rene,

I like this. I do a lot of environment setup via environment variables.
Linux loves this stuff, been doing it for ages now.

Please proceed.




On 03/14/12 12:18, rvjansen wrote:

>  
>
> Please shoot:
>
> DESIGN FOR COMPILER INDEPENDENCE OF THE NETREXX
> TRANSLATOR
>
> RATIONALE
>
> For several reasons one would want to exchange
> the compiler that is called by the NetRexx translator for the purpose of
> AOT (ahead-of-time) compiling.
>
> Some of these are:
>
> 1) no Java SDK
> present but JRE present on customer systems (the majority of cases in my
> reality)
> 2) exotic platforms where SDK is installed but compiler class
> hard to find
> 3) (potential) bug in compiler version that is available
> 4)
> first install for new and interested users fails on compiler class not
> found on classpath; user loses interest
>
> SOLUTION Make an environment
> variable available on platforms that support it that enables the code in
> RxTranslator to find an alternative compiler class on the
> classpath.
>
> This environment variable takes the form
> of:
>
> nrx.compiler=x
>
> where the default call would be
> System.getProperty("nrx.compiler","javac"), i.e. when the property is
> not found, the translator defaults to the compiler that is also called
> by javac.
>
> Values of x can initially be _javac_ or _ecj_.
>
> ecj is the
> eclipse batch compiler. An installer could do a testrun of a compile
> using javac and fall back to ecj if it encounters the exception that
> indicates it is not found on the classpath. This implies we have to
> deliver ecj.jar (this is how I call it for short, it has a long and
> unfriendly name containing release info). We control the placement of
> this jar in the installer, and will place it next to NetRexxC.jar. When
> the testrun does not find it, the installer can suggest to set the
> variable or do that itself.
>
> CONSEQUENCES The call to the compiler class
> needs to use reflective loading because otherwise there will be a
> linking dependency introduced to it. Javac ("sun.tools.javac") was never
> reflectively loaded because it was assumed that it was there, due to the
> requirements for the translator package. However, this will make
> compiling the translator fail on the aforementioned systems.
>
> (Note that
> it is still possible to generate java source for the compiler on another
> system, and compile this in a standalone run on a system that has the
> eclipse compiler but not the SDK - this was recently verified. This is
> possible because no NetRexx runtime class is used in the translator.
> This has as a consequence that either '==' or '.equals' must be used in
> the implementation - the normal equality operator '=' implies
> decimal.)
>
> When called by the translator, decisions must be taken what
> to do with the output. This also in the light of the 'lint'-like
> capabilities of the Eclipse compiler, which is not unlike the older
> Jikes tool.
>
> It must be positively verified that the interpreter works
> (c.q. keeps working) when compiling is not
> possible.
>
> ALTERNATIVES
>
> Alternatively, the whole line of compiler
> invocation to be executed could be specified. I am proponent of
> releasing a limited set of possibilities, with compilers that we have
> verified to work, which at this point are javac and ecj. The true
> tinkerer can solve this problem him/herself probably using the source
> code if so required.
>
> Please let me know what you think. I will proceed
> to enter the design into a support issue, and schedule its
> implementation when there is sufficient support.
>
> best regards,
>
> René
> Jansen.
>
>  
>
>
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPYRZHAAoJECl05UsMgeT92ukH/0+9F0Rq4/tSWuKtzV3JT+6a
aNvEOjKQKex4PhVkWx0JpDDVIUmXsgZWxQwOXjknAjhg09O5HEAyEGgV7fbXLjaG
eHLzCzWm4P9kQGlZ5QVcHDbU4jKAu1GrZ9OZGuE0pToHppyyYu13+TxNJCxJBrRl
Bv2xeMFIEHlgkNRCFRBeUGSfCKwhnuU/eCKr0ct1DRfi76EfZd0GxEqPGDoS7lYs
dZbwivp97Z4hmGMYpeRCK9gF4RRUW8yzAED+Q+Mk+pEys0IjxoTUcAM1APgdWCjP
1l+KmiqZmv2dUfI6iYmrZ8YCDOuSD8sM8Mk0NPwOBjFAt9KQCVctOuneNR3jSU0=
=NhAE
-----END PGP SIGNATURE-----

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

[Tom Maynard]

On 3/14/2012 11:18 AM, rvjansen wrote:

Please shoot:

Design for compiler independence of the NetRexx translator

I don't have any substantive complaints with your idea (and project, and implementation).  In many cases it's probably an excellent idea to get rank beginners off to a running start -- and not require them to install Java separately -- and just hold the full JDK as an "upgrade option" for the future, if ever.

I also already know that discovering the (pre)existence of the JDK during installation is non-trivial, platform dependent, and subject to error.  Having NetRexx bring its own compiler along makes the installer's job much easier.

So, you can say that I'm rather in favor of the idea.

My observations (not strong enough to be called "objections"):

1. It means there's one more piece (i.e. the compiler) that needs to be kept up-to-date, and it is something that RexxLA does not maintain.  That's not a big problem, but it is one more thing to remember when release dates roll around.

2. NetRexx is one of a growing family of "Alternative Languages on the JVM."  How many of those other languages deliver their own compiler?  I mean: it's a language compiled for the JVM, and expecting the user to have the JDK is not unreasonable.  Does Groovy, Clojure, Scala, ..., or even Rhino deliver its own compiler at install time?  No, and the reason is that a user of a language on the JVM will have (or get) the JDK.  In some cases those languages compile directly to byte codes and a separate compiler is unnecessary -- but not all of them.

I don't think either of these issues is big enough to offset the advantages I mentioned at the outset.  So count this as a rather verbose +1 for your idea.

Tom.


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

[Aviatrexx]

On 3/15/12 01:11 Tom Maynard said:

>   On 3/14/2012 11:18 AM, rvjansen wrote:
>> Please shoot:
>>
>> *Design for compiler independence of the NetRexx translator*
>
> I don't have any substantive complaints with your idea (and project, and
> implementation).  In many cases it's probably an excellent idea to get
> rank beginners off to a running start -- and not require them to install
> Java separately -- and just hold the full JDK as an "upgrade option" for
> the future, if ever.
>
> 2. NetRexx is one of a growing family of "Alternative Languages on the
> JVM."  How many of those other languages deliver their own compiler?

Perhaps none of them.  However,
  1. None of them were designed for the beginner.  Most, if not all of
them were created to make experienced programmers more productive in
one way or another.
  2. If you ask your average non-Java programmer "Do you have Java?",
he will say "Sure, I've even got it running in my browser!".  Fine
distinctions between JRE and JDE are invisible (pretty much by
definition) to the non-Java programmer (c.f. "javascript").  I think a
perusal of this list's archives will reinforce that.

As for the advisability of using an environment variable: there aren't
that many platform independent ways to store state.  $nrx.compiler
sure beats the hell out of a registry entry, although an .rc file
might allay the objections.

I'm sure the Law of Unintended Consequences will rear its ugly head
soon enough, but I think René's proposal is sound.

-Chip-

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

[ThSITC]

Hi Rene,
   I would vote for the proposed environment variable.
Thomas Schneider.
=======================================
Am 14.03.2012 17:18, schrieb rvjansen:

Please shoot:

Design for compiler independence of the NetRexx translator

Rationale

For several reasons one would want to exchange the compiler that is called by the NetRexx translator for the purpose of AOT (ahead-of-time) compiling.

Some of these are:

1) no Java SDK present but JRE present on customer systems (the majority of cases in my reality)
2) exotic platforms where SDK is installed but compiler class hard to find
3) (potential) bug in compiler version that is available
4) first install for new and interested users fails on compiler class not found on classpath; user loses interest

Solution Make an environment variable available on platforms that support it that enables the code in RxTranslator to find an alternative compiler class on the classpath.

This environment variable takes the form of:

nrx.compiler=x

where the default call would be System.getProperty("nrx.compiler","javac"), i.e. when the property is not found, the translator defaults to the compiler that is also called by javac.

Values of x can initially be javac or ecj.

ecj is the eclipse batch compiler. An installer could do a testrun of a compile using javac and fall back to ecj if it encounters the exception that indicates it is not found on the classpath. This implies we have to deliver ecj.jar (this is how I call it for short, it has a long and unfriendly name containing release info). We control the placement of this jar in the installer, and will place it next to NetRexxC.jar. When the testrun does not find it, the installer can suggest to set the variable or do that itself.

Consequences The call to the compiler class needs to use reflective loading because otherwise there will be a linking dependency introduced to it. Javac ("sun.tools.javac") was never reflectively loaded because it was assumed that it was there, due to the requirements for the translator package. However, this will make compiling the translator fail on the aforementioned systems.

(Note that it is still possible to generate java source for the compiler on another system, and compile this in a standalone run on a system that has the eclipse compiler but not the SDK - this was recently verified. This is possible because no NetRexx runtime class is used in the translator. This has as a consequence that either '==' or '.equals' must be used in the implementation - the normal equality operator '=' implies decimal.)

When called by the translator, decisions must be taken what to do with the output. This also in the light of the 'lint'-like capabilities of the Eclipse compiler, which is not unlike the older Jikes tool.

It must be positively verified that the interpreter works (c.q. keeps working) when compiling is not possible.

Alternatives

Alternatively, the whole line of compiler invocation to be executed could be specified. I am proponent of releasing a limited set of possibilities, with compilers that we have verified to work, which at this point are javac and ecj. The true tinkerer can solve this problem him/herself probably using the source code if so required.

Please let me know what you think. I will proceed to enter the design into a support issue, and schedule its implementation when there is sufficient support.

best regards,

René Jansen.

_______________________________________________
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/

[Mike Cowlishaw]

 
Also don't forget that the NetRexx code is 'almost ready' to emit bytecodes
itself.  I forget how many of the hooks, etc., are actually there .. but that
was my original goal, if time (etc.) had been available.  So there's no need to
depend on an 'external' Java -> Bytecode compiler.

Mike

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

[Patric Bechtel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi René,

I like the idea itself, but I'm all against environment variables. My
working OS's are almost exclusive Unixes, but I know that almost all
Windows and Mac users have no clue about them at all, let alone
knowing where and how to set them system wide (if you want that).
Apart from that, I personally prefer command line parameters and conf
files more.

I would suggest using a simple command line parameter and some
intelligent behaviour of the NetRexx compiler itself - and in the
error case an intelligent error message precisely stating the problem.
Everyone capable of reading would then just use one of the possible
command line options to switch to the desired behaviour, or use the
interpreter if they are just "playing".

Apart from that, the option selection first trying javac, then ecj
seems reasonable.

rvjansen schrieb am 14.03.2012 17:18:

> Please shoot:
>
> *Design for compiler independence of the NetRexx translator*
>
> **
>
> *Rationale*
>
> For several reasons one would want to exchange the compiler that is
> called by the NetRexx translator for the purpose of AOT
> (ahead-of-time) compiling.
>
> Some of these are:
>
> 1) no Java SDK present but JRE present on customer systems (the
> majority of cases in my reality) 2) exotic platforms where SDK is
> installed but compiler class hard to find 3) (potential) bug in
> compiler version that is available 4) first install for new and
> interested users fails on compiler class not found on classpath;
> user loses interest
>
> *Solution *Make an environment variable available on platforms that
> support it that enables the code in RxTranslator to find an
> alternative compiler class on the classpath.
>
> This environment variable takes the form of:
>
> nrx.compiler=x
>
> where the default call would be
> System.getProperty("nrx.compiler","javac"), i.e. when the property
> is not found, the translator defaults to the compiler that is also
> called by javac.
>
> Values of x can initially be /javac/ or /ecj/.
>
> ecj is the eclipse batch compiler. An installer could do a testrun
> of a compile using javac and fall back to ecj if it encounters the
> exception that indicates it is not found on the classpath. This
> implies we have to deliver ecj.jar (this is how I call it for
> short, it has a long and unfriendly name containing release info).
> We control the placement of this jar in the installer, and will
> place it next to NetRexxC.jar. When the testrun does not find it,
> the installer can suggest to set the variable or do that itself.
>
> *Consequences *The call to the compiler class needs to use
> reflective loading because otherwise there will be a linking
> dependency introduced to it. Javac ("sun.tools.javac") was never
> reflectively loaded because it was assumed that it was there, due
> to the requirements for the translator package. However, this will
> make compiling the translator fail on the aforementioned systems.
>
> (Note that it is still possible to generate java source for the
> compiler on another system, and compile this in a standalone run on
> a system that has the eclipse compiler but not the SDK - this was
> recently verified. This is possible because no NetRexx runtime
> class is used in the translator. This has as a consequence that
> either '==' or '.equals' must be used in the implementation - the
> normal equality operator '=' implies decimal.)
>
> When called by the translator, decisions must be taken what to do
> with the output. This also in the light of the 'lint'-like
> capabilities of the Eclipse compiler, which is not unlike the older
> Jikes tool.
>
>
>
> It must be positively verified that the interpreter works (c.q.
> keeps working) when compiling is not possible.
>
> *Alternatives*
>
> Alternatively, the whole line of compiler invocation to be executed
> could be specified. I am proponent of releasing a limited set of
> possibilities, with compilers that we have verified to work, which
> at this point are javac and ecj. The true tinkerer can solve this
> problem him/herself probably using the source code if so required.
>
>
>
> Please let me know what you think. I will proceed to enter the
> design into a support issue, and schedule its implementation when
> there is sufficient support.

- --
cu, Patric
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: GnuPT 2.5.2

iEYEARECAAYFAk9i91gACgkQfGgGu8y7ypAVkgCgyR1/Zs+s0ufpqHpQ3ZcQE3yA
sSIAoIFI0TW60mIn46ee5IQj+gZKzlKV
=mvGn
-----END PGP SIGNATURE-----

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

[kenner]

I remember I used to have a nifty little edit macro that would take the source code that I was in the middle of editing and format it. All the indents would be uniform and the "do"'s and "end"'s and so on where all lined up. Who has a good one of those? What's the name. I found rexxform but it's broke.


Kenneth Klein

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

[billfen]

It seems to me that the first step that should be taken is to update
NetRexx so that it uses the standard API for calling the javac
compiler.  The javax library has been available for several years and it
is well documented (e.g.
http://www.ibm.com/developerworks/java/library/j-jcomp/index.html and
http://docs.oracle.com/javase/6/docs/api/javax/tools/JavaCompiler.html and
http://docs.oracle.com/javase/6/docs/technotes/tools/windows/javac.html#proginterface 
).

For backward compatibility, a NetRexx option should be added so that the
currently used interface "sun.tools.javac.Main(" could still be used for
Java levels before the javax.tools library and the standard API was
available.

That way, any java compiler (using the standard API) can be used simply
by putting it on the class path, and no environment variable is necessary.

As discussed in a note from Jason Monroe Martin last December ("Building
NetRexx to use the Eclipse Compiler"), that should cover the Eclipse
compiler.  It is quite likely that at this point, all Java compilers of
interest will use the standard API.  I assume that had the standard API
been available when Mike wrote NetRexx, he would have used it.

Using environment variables to add things to the classpath is a
different discussion, I think.

As I remember, wasn't the compiler interface situation was discussed
last fall?

Perhaps I'm missing something.  Are there situations in which the
standard API is not sufficient?

Bill

On 3/16/2012 4:18 AM, Patric Bechtel wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi René,
>
> I like the idea itself, but I'm all against environment variables. My
> working OS's are almost exclusive Unixes, but I know that almost all
> Windows and Mac users have no clue about them at all, let alone
> knowing where and how to set them system wide (if you want that).
> Apart from that, I personally prefer command line parameters and conf
> files more.
>
> I would suggest using a simple command line parameter and some
> intelligent behaviour of the NetRexx compiler itself - and in the
> error case an intelligent error message precisely stating the problem.
> Everyone capable of reading would then just use one of the possible
> command line options to switch to the desired behaviour, or use the
> interpreter if they are just "playing".
>
> Apart from that, the option selection first trying javac, then ecj
> seems reasonable.
>
> rvjansen schrieb am 14.03.2012 17:18:
>> Please shoot:
>>
>> *Design for compiler independence of the NetRexx translator*
>>
>> **
>>
>> *Rationale*
>>
>> For several reasons one would want to exchange the compiler that is
>> called by the NetRexx translator for the purpose of AOT
>> (ahead-of-time) compiling.
>>
>> Some of these are:
>>
>> 1) no Java SDK present but JRE present on customer systems (the
>> majority of cases in my reality) 2) exotic platforms where SDK is
>> installed but compiler class hard to find 3) (potential) bug in
>> compiler version that is available 4) first install for new and
>> interested users fails on compiler class not found on classpath;
>> user loses interest
>>
>> *Solution *Make an environment variable available on platforms that
>> support it that enables the code in RxTranslator to find an
>> alternative compiler class on the classpath.
>>
>> This environment variable takes the form of:
>>
>> nrx.compiler=x
>>
>> where the default call would be
>> System.getProperty("nrx.compiler","javac"), i.e. when the property
>> is not found, the translator defaults to the compiler that is also
>> called by javac.
>>
>> Values of x can initially be /javac/ or /ecj/.
>>
>> ecj is the eclipse batch compiler. An installer could do a testrun
>> of a compile using javac and fall back to ecj if it encounters the
>> exception that indicates it is not found on the classpath. This
>> implies we have to deliver ecj.jar (this is how I call it for
>> short, it has a long and unfriendly name containing release info).
>> We control the placement of this jar in the installer, and will
>> place it next to NetRexxC.jar. When the testrun does not find it,
>> the installer can suggest to set the variable or do that itself.
>>
>> *Consequences *The call to the compiler class needs to use
>> reflective loading because otherwise there will be a linking
>> dependency introduced to it. Javac ("sun.tools.javac") was never
>> reflectively loaded because it was assumed that it was there, due
>> to the requirements for the translator package. However, this will
>> make compiling the translator fail on the aforementioned systems.
>>
>> (Note that it is still possible to generate java source for the
>> compiler on another system, and compile this in a standalone run on
>> a system that has the eclipse compiler but not the SDK - this was
>> recently verified. This is possible because no NetRexx runtime
>> class is used in the translator. This has as a consequence that
>> either '==' or '.equals' must be used in the implementation - the
>> normal equality operator '=' implies decimal.)
>>
>> When called by the translator, decisions must be taken what to do
>> with the output. This also in the light of the 'lint'-like
>> capabilities of the Eclipse compiler, which is not unlike the older
>> Jikes tool.
>>
>>
>>
>> It must be positively verified that the interpreter works (c.q.
>> keeps working) when compiling is not possible.
>>
>> *Alternatives*
>>
>> Alternatively, the whole line of compiler invocation to be executed
>> could be specified. I am proponent of releasing a limited set of
>> possibilities, with compilers that we have verified to work, which
>> at this point are javac and ecj. The true tinkerer can solve this
>> problem him/herself probably using the source code if so required.
>>
>>
>>
>> Please let me know what you think. I will proceed to enter the
>> design into a support issue, and schedule its implementation when
>> there is sufficient support.
> - --
> cu, Patric
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: GnuPT 2.5.2
>
> iEYEARECAAYFAk9i91gACgkQfGgGu8y7ypAVkgCgyR1/Zs+s0ufpqHpQ3ZcQE3yA
> sSIAoIFI0TW60mIn46ee5IQj+gZKzlKV
> =mvGn
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.1913 / Virus Database: 2114/4872 - Release Date: 03/15/12
>
>
>

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

[George Hovey-2]

Does the possibility of multiple compilers have implications for compiler diagnostics?  For example, I've experimented with tools that reformat NetRexxC's output in ways that I find helpful.  This is made somewhat difficult because AFAIK there is no specification for the output, and I have to deduce this from examples, and occasionally modify my program as new cases turn up.  It sounds like multiple compilers might make this more problematic.

Could/should/would NetRexxC process all compiler summary output into a common (defined) format?

On Fri, Mar 16, 2012 at 1:35 PM, Bill Fenlason <[hidden email]> wrote:

It seems to me that the first step that should be taken is to update NetRexx so that it uses the standard API for calling the javac compiler.  The javax library has been available for several years and it is well documented (e.g.
http://www.ibm.com/developerworks/java/library/j-jcomp/index.html and
http://docs.oracle.com/javase/6/docs/api/javax/tools/JavaCompiler.html and
http://docs.oracle.com/javase/6/docs/technotes/tools/windows/javac.html#proginterface ).

For backward compatibility, a NetRexx option should be added so that the currently used interface "sun.tools.javac.Main(" could still be used for Java levels before the javax.tools library and the standard API was available.

That way, any java compiler (using the standard API) can be used simply by putting it on the class path, and no environment variable is necessary.

As discussed in a note from Jason Monroe Martin last December ("Building NetRexx to use the Eclipse Compiler"), that should cover the Eclipse compiler.  It is quite likely that at this point, all Java compilers of interest will use the standard API.  I assume that had the standard API been available when Mike wrote NetRexx, he would have used it.

Using environment variables to add things to the classpath is a different discussion, I think.

As I remember, wasn't the compiler interface situation was discussed last fall?

Perhaps I'm missing something.  Are there situations in which the standard API is not sufficient?

Bill

On 3/16/2012 4:18 AM, Patric Bechtel wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi René,

I like the idea itself, but I'm all against environment variables. My
working OS's are almost exclusive Unixes, but I know that almost all
Windows and Mac users have no clue about them at all, let alone
knowing where and how to set them system wide (if you want that).
Apart from that, I personally prefer command line parameters and conf
files more.

I would suggest using a simple command line parameter and some
intelligent behaviour of the NetRexx compiler itself - and in the
error case an intelligent error message precisely stating the problem.
Everyone capable of reading would then just use one of the possible
command line options to switch to the desired behaviour, or use the
interpreter if they are just "playing".

Apart from that, the option selection first trying javac, then ecj
seems reasonable.

rvjansen schrieb am 14.03.2012 17:18:

Please shoot:

*Design for compiler independence of the NetRexx translator*

**

*Rationale*

For several reasons one would want to exchange the compiler that is
called by the NetRexx translator for the purpose of AOT
(ahead-of-time) compiling.

Some of these are:

1) no Java SDK present but JRE present on customer systems (the
majority of cases in my reality) 2) exotic platforms where SDK is
installed but compiler class hard to find 3) (potential) bug in
compiler version that is available 4) first install for new and
interested users fails on compiler class not found on classpath;
user loses interest

*Solution *Make an environment variable available on platforms that
support it that enables the code in RxTranslator to find an
alternative compiler class on the classpath.

This environment variable takes the form of:

nrx.compiler=x

where the default call would be
System.getProperty("nrx.compiler","javac"), i.e. when the property
is not found, the translator defaults to the compiler that is also
called by javac.

Values of x can initially be /javac/ or /ecj/.

ecj is the eclipse batch compiler. An installer could do a testrun
of a compile using javac and fall back to ecj if it encounters the
exception that indicates it is not found on the classpath. This
implies we have to deliver ecj.jar (this is how I call it for
short, it has a long and unfriendly name containing release info).
We control the placement of this jar in the installer, and will
place it next to NetRexxC.jar. When the testrun does not find it,
the installer can suggest to set the variable or do that itself.

*Consequences *The call to the compiler class needs to use
reflective loading because otherwise there will be a linking
dependency introduced to it. Javac ("sun.tools.javac") was never
reflectively loaded because it was assumed that it was there, due
to the requirements for the translator package. However, this will
make compiling the translator fail on the aforementioned systems.

(Note that it is still possible to generate java source for the
compiler on another system, and compile this in a standalone run on
a system that has the eclipse compiler but not the SDK - this was
recently verified. This is possible because no NetRexx runtime
class is used in the translator. This has as a consequence that
either '==' or '.equals' must be used in the implementation - the
normal equality operator '=' implies decimal.)

When called by the translator, decisions must be taken what to do
with the output. This also in the light of the 'lint'-like
capabilities of the Eclipse compiler, which is not unlike the older
Jikes tool.



It must be positively verified that the interpreter works (c.q.
keeps working) when compiling is not possible.

*Alternatives*

Alternatively, the whole line of compiler invocation to be executed
could be specified. I am proponent of releasing a limited set of
possibilities, with compilers that we have verified to work, which
at this point are javac and ecj. The true tinkerer can solve this
problem him/herself probably using the source code if so required.



Please let me know what you think. I will proceed to enter the
design into a support issue, and schedule its implementation when
there is sufficient support.

- -- cu, Patric
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: GnuPT 2.5.2

iEYEARECAAYFAk9i91gACgkQfGgGu8y7ypAVkgCgyR1/Zs+s0ufpqHpQ3ZcQE3yA
sSIAoIFI0TW60mIn46ee5IQj+gZKzlKV
=mvGn
-----END PGP SIGNATURE-----

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

-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1913 / Virus Database: 2114/4872 - Release Date: 03/15/12

_______________________________________________
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/

[Jeff Hennick]

On 3/16/2012 4:08 PM, George Hovey wrote:

> Does the possibility of multiple compilers have implications for
> compiler diagnostics?  For example, I've experimented with tools that
> reformat NetRexxC's output in ways that I find helpful.  This is made
> somewhat difficult because AFAIK there is no specification for the
> output, and I have to deduce this from examples, and occasionally
> modify my program as new cases turn up.  It sounds like multiple
> compilers might make this more problematic.
>
> Could/should/would NetRexxC process all compiler summary output into a
> common (defined) format?

IMHO, No.  That would require way too much knowledge of each potential
compiler, when the goal is to need to know nothing about the compiler.  
Formatters/editor-links should be via pipes or "plugin filters" or [?].  
The responses from the compiler and the input format to whatever comes
next (and personal preferences: George's obviously are different from
the compiler's designers) are far too numerous.

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

[Rony G. Flatscher (wu-wien)]

Hi Mike,

On 15.03.2012 20:43, Mike Cowlishaw wrote:
> Also don't forget that the NetRexx code is 'almost ready' to emit bytecodes
> itself.  I forget how many of the hooks, etc., are actually there .. but that
> was my original goal, if time (etc.) had been available.  So there's no need to
> depend on an 'external' Java -> Bytecode compiler.
Would it be possible for you to give a presentation at this year's International Rexx Symposium in
May where you would lay out, explain the architecture and how one could take advantage of it to
generate byte code on the fly creating valid class byte streams at runtime? Would it be possible to
generate Android Dalvik byte-codes on the fly as well?

Best regards,

---rony

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

[Mike Cowlishaw]

Hi,

> On 15.03.2012 20:43, Mike Cowlishaw wrote:
> > Also don't forget that the NetRexx code is 'almost ready' to emit
> > bytecodes itself.  I forget how many of the hooks, etc.,
> > are actually
> > there .. but that was my original goal, if time (etc.) had been
> > available.  So there's no need to depend on an 'external'
> > Java -> Bytecode compiler.
>
> Would it be possible for you to give a presentation at this
> year's International Rexx Symposium in May where you would
> lay out, explain the architecture and how one could take
> advantage of it to generate byte code on the fly creating
> valid class byte streams at runtime?

It's ten+ years since I looked at the code, so I don't think
I'm the best person for that anymore.

Also see the existing presentation on internals under the NetRexx
entry at: http://speleotrove.com/#computing 

>                                      Would it be possible to
> generate Android Dalvik byte-codes on the fly as well?

No idea.  If similar to Java then should be possible.

Mike

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

[rvjansen]

Hi Rony,

however interesting, I think it will require some study to achieve this; it is currently not on the priorities list, and the first priority will always be to be compatible with Java. As it happens, just today I was made aware of https://github.com/qmx/jitescript which seems interesting enough for the purpose of rounding out the class file generation capacity of NetRexx.

A student project (if you can find one very clever student)?

best regards,

René.

On 21 mrt. 2012, at 10:36, Rony G. Flatscher wrote:

> Hi Mike,
>
> On 15.03.2012 20:43, Mike Cowlishaw wrote:
>> Also don't forget that the NetRexx code is 'almost ready' to emit bytecodes
>> itself.  I forget how many of the hooks, etc., are actually there .. but that
>> was my original goal, if time (etc.) had been available.  So there's no need to
>> depend on an 'external' Java -> Bytecode compiler.
> Would it be possible for you to give a presentation at this year's International Rexx Symposium in
> May where you would lay out, explain the architecture and how one could take advantage of it to
> generate byte code on the fly creating valid class byte streams at runtime? Would it be possible to
> generate Android Dalvik byte-codes on the fly as well?
>
> Best regards,
>
> ---rony
>
> _______________________________________________
> 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/