netrexx site

[David Requena]

Well, what it would automatically break is the warranty of getting compatible classes we have today. Going through javac assures no NetRexx generated code will yield non-compliant binary classes, event in the event of a NetRexxC bug.

More over, I still haven't heard any compelling reasons/advantages for such a switch..

2011/6/10 Kermit Kiser <[hidden email]>

I admit to being a little puzzled about why directly producing bytecode would break Java compatibility. I think the JVM verifies that the bytecode is legal and thus any such should be compatible.

Anyway, the advantages of producing bytecode that I see are that one could do NetRexx programming on a computer with the JRE and not have to require the JDK; also some ANT build files might be simplified. However, the important advantage of producing Java source code is to allow Java and NetRexx programmers to work together more easily. Granted, the two output forms are not mutually exclusive and the bytecode could easily be tested for differences.

-- Kermit

On 6/10/2011 1:40 PM, Thomas Schneider wrote:

When, and only when a NetRexx Compiler would directly emit BYTE-Code, it will NOT, at all, BREAK the Java inter-operability.

But this should be an option of the respective NetRexx compiler, IMHO.

Thomas.
========================================================
Am 10.06.2011 22:17, schrieb George Hovey:

Alan,

>>The day NetRexx stops doing this and goes directly to bytecode is the day I stop using NetRexx.

Hear, hear!   I have argued, no doubt ad nauseam, that compatibility with Java at the class level should be an essential claim of NetRexx, and be prominently asserted at the web site.  This would signal that Java and NetRexx development can be safely mixed and, IMO, act as a powerful attractant to Java programmers.  There has been some talk in this forum of emitting byte code.  Doing so would forever break that compact.
George

On Fri, Jun 10, 2011 at 2:39 PM, Alan Sampson <[hidden email]> wrote:

On 10 June 2011 11:21, George Hovey <[hidden email]> wrote:

Bob,
BTW, NetRexx is not a JVM language: it is a translator whose target language is Java source code.  Of course, the Java compiler then produces JVM code.  The crucial point is that this guarantees that NetRexx classes are totally compatible with Java classes.
George

Good point and one that should be stressed.   NetRexx's ability to generate Java source is a huge benefit when building complex projects as you can mix and match compilation units and just take the NetRexx generated source and merge it into the bigger "Java only" suite thus allowing developers to work in the environment they're most comfortable in.

The day NetRexx stops doing this and goes directly to bytecode is the day I stop using NetRexx.

A.



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

_______________________________________________
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 (www.thsitc.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/

--
Saludos / Regards,
David Requena

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

[David Requena]

Well, what it would automatically break is the warranty of getting compatible classes we have today. Going through javac assures no NetRexx generated code will yield non-compliant binary classes, event in the event of a NetRexxC bug.

More over, I still haven't heard any compelling reasons/advantages for such a switch..

2011/6/10 Kermit Kiser <[hidden email]>

I admit to being a little puzzled about why directly producing bytecode would break Java compatibility. I think the JVM verifies that the bytecode is legal and thus any such should be compatible.

Anyway, the advantages of producing bytecode that I see are that one could do NetRexx programming on a computer with the JRE and not have to require the JDK; also some ANT build files might be simplified. However, the important advantage of producing Java source code is to allow Java and NetRexx programmers to work together more easily. Granted, the two output forms are not mutually exclusive and the bytecode could easily be tested for differences.

-- Kermit

On 6/10/2011 1:40 PM, Thomas Schneider wrote:

When, and only when a NetRexx Compiler would directly emit BYTE-Code, it will NOT, at all, BREAK the Java inter-operability.

But this should be an option of the respective NetRexx compiler, IMHO.

Thomas.
========================================================
Am 10.06.2011 22:17, schrieb George Hovey:

Alan,

>>The day NetRexx stops doing this and goes directly to bytecode is the day I stop using NetRexx.

Hear, hear!   I have argued, no doubt ad nauseam, that compatibility with Java at the class level should be an essential claim of NetRexx, and be prominently asserted at the web site.  This would signal that Java and NetRexx development can be safely mixed and, IMO, act as a powerful attractant to Java programmers.  There has been some talk in this forum of emitting byte code.  Doing so would forever break that compact.
George

On Fri, Jun 10, 2011 at 2:39 PM, Alan Sampson <[hidden email]> wrote:

On 10 June 2011 11:21, George Hovey <[hidden email]> wrote:

Bob,
BTW, NetRexx is not a JVM language: it is a translator whose target language is Java source code.  Of course, the Java compiler then produces JVM code.  The crucial point is that this guarantees that NetRexx classes are totally compatible with Java classes.
George

Good point and one that should be stressed.   NetRexx's ability to generate Java source is a huge benefit when building complex projects as you can mix and match compilation units and just take the NetRexx generated source and merge it into the bigger "Java only" suite thus allowing developers to work in the environment they're most comfortable in.

The day NetRexx stops doing this and goes directly to bytecode is the day I stop using NetRexx.

A.



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

_______________________________________________
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 (www.thsitc.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/

--
Saludos / Regards,
David Requena

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

[Joe Niffen]

There have been a few NetRexx books and guides from sometime ago, IBM
Redbook and Mike's NetRexx.

My question is, are those still valid for learning NetRexx or is the
last version different enough that they wouldn't be a guide to start off
with.

Any input will be appreciated.

Thanks

Joe

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

[KP Kirchdörfer]

Am Samstag, 11. Juni 2011, um 01:34:30 schrieben Sie:
> There have been a few NetRexx books and guides from sometime ago, IBM
> Redbook and Mike's NetRexx.
>
> My question is, are those still valid for learning NetRexx or is the
> last version different enough that they wouldn't be a guide to start off
> with.
>
> Any input will be appreciated.

Yes, they are still valid.
Though you may have an additional look into the supplement for 2.0.2 from
http://www-01.ibm.com/software/awdtools/netrexx/library.html
which may add some information about language changes not reflected in the
books you mentioned.

The current availble download is still the 2.05 version, the last release from
IBM, and the upcoming opensource version will not be that different - as Rene
stated on this list.

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

[rvjansen]

I agree, but we are not home free, even without byte code engineering, because we also have to take care of the incompatible class file formats that the new versions of javac produce. For example, for the 3.00 translator, we must be careful to produce the classfiles with the 1.4 flag; this never has been a problem before but now it does. This also implies there cannot be Java 5 calls used for generated Java source - now no problem but something we must remember very well. At the moment the translator is fully Java 1.1 compatible;  we might have to decide at some point that in order to support more modern Java features, the minimum level of Java that is required will increase. This must be part of the roadmap that we will put together.

René.

On Jun 11, 2011, at 12:58 AM, David Requena wrote:

Well, what it would automatically break is the warranty of getting compatible classes we have today. Going through javac assures no NetRexx generated code will yield non-compliant binary classes, event in the event of a NetRexxC bug.

More over, I still haven't heard any compelling reasons/advantages for such a switch..

2011/6/10 Kermit Kiser <[hidden email]>

I admit to being a little puzzled about why directly producing bytecode would break Java compatibility. I think the JVM verifies that the bytecode is legal and thus any such should be compatible.

Anyway, the advantages of producing bytecode that I see are that one could do NetRexx programming on a computer with the JRE and not have to require the JDK; also some ANT build files might be simplified. However, the important advantage of producing Java source code is to allow Java and NetRexx programmers to work together more easily. Granted, the two output forms are not mutually exclusive and the bytecode could easily be tested for differences.

-- Kermit

On 6/10/2011 1:40 PM, Thomas Schneider wrote:

When, and only when a NetRexx Compiler would directly emit BYTE-Code, it will NOT, at all, BREAK the Java inter-operability.

But this should be an option of the respective NetRexx compiler, IMHO.

Thomas.
========================================================
Am 10.06.2011 22:17, schrieb George Hovey:

Alan,

>>The day NetRexx stops doing this and goes directly to bytecode is the day I stop using NetRexx.

Hear, hear!   I have argued, no doubt ad nauseam, that compatibility with Java at the class level should be an essential claim of NetRexx, and be prominently asserted at the web site.  This would signal that Java and NetRexx development can be safely mixed and, IMO, act as a powerful attractant to Java programmers.  There has been some talk in this forum of emitting byte code.  Doing so would forever break that compact.
George

On Fri, Jun 10, 2011 at 2:39 PM, Alan Sampson <[hidden email]> wrote:

On 10 June 2011 11:21, George Hovey <[hidden email]> wrote:

Bob,
BTW, NetRexx is not a JVM language: it is a translator whose target language is Java source code.  Of course, the Java compiler then produces JVM code.  The crucial point is that this guarantees that NetRexx classes are totally compatible with Java classes.
George

Good point and one that should be stressed.   NetRexx's ability to generate Java source is a huge benefit when building complex projects as you can mix and match compilation units and just take the NetRexx generated source and merge it into the bigger "Java only" suite thus allowing developers to work in the environment they're most comfortable in.

The day NetRexx stops doing this and goes directly to bytecode is the day I stop using NetRexx.

A.



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

_______________________________________________
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 (www.thsitc.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/

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

[Fernando Cassia-2]

On Fri, Jun 10, 2011 at 21:06, René Jansen <[hidden email]> wrote:
> At the moment the translator is fully Java 1.1 compatible;  we might have to
> decide at some point that in order to support more modern Java features, the
> minimum level of Java that is required will increase. This must be part of
> the roadmap that we will put together.

Java 1.1 is ancient, however. Anything below Java 6 is fossilized.

Read James Gosling´s rant against people still using the Java 1.4 API.

http://www.dzone.com/links/james_gosling_tells_java_142_users_to_get_with_th.html

My understanding is that Java 7 (1.7) will be released next week.

And JDK8 is already in the works. Now that it´s open source and
OpenJDK is going to end up in all Linux distros (I believe it´s in
Fedora already), that means the "standard" level of Java will probably
be Java 7 by the end of this year...

It´s indeed silly not being able to use the newer APIs...
FC

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

[measel]

Backwards compatibility is a wonderful thing. 

------Original Message------
From: Fernando Cassia
To: IBM Netrexx
ReplyTo: IBM Netrexx
Subject: Re: [Ibm-netrexx] Java Byte Code (was netrexx site)
Sent: Jun 10, 2011 7:20 PM

On Fri, Jun 10, 2011 at 21:06, René Jansen <[hidden email]> wrote:
> At the moment the translator is fully Java 1.1 compatible;  we might have to
> decide at some point that in order to support more modern Java features, the
> minimum level of Java that is required will increase. This must be part of
> the roadmap that we will put together.

Java 1.1 is ancient, however. Anything below Java 6 is fossilized.

Read James Gosling´s rant against people still using the Java 1.4 API.

http://www.dzone.com/links/james_gosling_tells_java_142_users_to_get_with_th.html

My understanding is that Java 7 (1.7) will be released next week.

And JDK8 is already in the works. Now that it´s open source and
OpenJDK is going to end up in all Linux distros (I believe it´s in
Fedora already), that means the "standard" level of Java will probably
be Java 7 by the end of this year...

It´s indeed silly not being able to use the newer APIs...
FC

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

[David Requena]

Oh, I always forget about the interpreter...

That one will get a lot more useful once the user code has not to go through the file system to parse classes.

isn't it sweet? now we c

2011/6/11 René Jansen <[hidden email]>

I agree, but we are not home free, even without byte code engineering, because we also have to take care of the incompatible class file formats that the new versions of javac produce. For example, for the 3.00 translator, we must be careful to produce the classfiles with the 1.4 flag; this never has been a problem before but now it does. This also implies there cannot be Java 5 calls used for generated Java source - now no problem but something we must remember very well. At the moment the translator is fully Java 1.1 compatible;  we might have to decide at some point that in order to support more modern Java features, the minimum level of Java that is required will increase. This must be part of the roadmap that we will put together.

René.

On Jun 11, 2011, at 12:58 AM, David Requena wrote:

Well, what it would automatically break is the warranty of getting compatible classes we have today. Going through javac assures no NetRexx generated code will yield non-compliant binary classes, event in the event of a NetRexxC bug.

More over, I still haven't heard any compelling reasons/advantages for such a switch..

2011/6/10 Kermit Kiser <[hidden email]>

I admit to being a little puzzled about why directly producing bytecode would break Java compatibility. I think the JVM verifies that the bytecode is legal and thus any such should be compatible.

Anyway, the advantages of producing bytecode that I see are that one could do NetRexx programming on a computer with the JRE and not have to require the JDK; also some ANT build files might be simplified. However, the important advantage of producing Java source code is to allow Java and NetRexx programmers to work together more easily. Granted, the two output forms are not mutually exclusive and the bytecode could easily be tested for differences.

-- Kermit

On 6/10/2011 1:40 PM, Thomas Schneider wrote:

When, and only when a NetRexx Compiler would directly emit BYTE-Code, it will NOT, at all, BREAK the Java inter-operability.

But this should be an option of the respective NetRexx compiler, IMHO.

Thomas.
========================================================
Am 10.06.2011 22:17, schrieb George Hovey:

Alan,

>>The day NetRexx stops doing this and goes directly to bytecode is the day I stop using NetRexx.

Hear, hear!   I have argued, no doubt ad nauseam, that compatibility with Java at the class level should be an essential claim of NetRexx, and be prominently asserted at the web site.  This would signal that Java and NetRexx development can be safely mixed and, IMO, act as a powerful attractant to Java programmers.  There has been some talk in this forum of emitting byte code.  Doing so would forever break that compact.
George

On Fri, Jun 10, 2011 at 2:39 PM, Alan Sampson <[hidden email]> wrote:

On 10 June 2011 11:21, George Hovey <[hidden email]> wrote:

Bob,
BTW, NetRexx is not a JVM language: it is a translator whose target language is Java source code.  Of course, the Java compiler then produces JVM code.  The crucial point is that this guarantees that NetRexx classes are totally compatible with Java classes.
George

Good point and one that should be stressed.   NetRexx's ability to generate Java source is a huge benefit when building complex projects as you can mix and match compilation units and just take the NetRexx generated source and merge it into the bigger "Java only" suite thus allowing developers to work in the environment they're most comfortable in.

The day NetRexx stops doing this and goes directly to bytecode is the day I stop using NetRexx.

A.



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

_______________________________________________
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 (www.thsitc.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/

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

--
Saludos / Regards,
David Requena

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

[measel]

Provide a command line interpreter shell.

NRX>say "hello free world"

Hello free world.

---

From: [hidden email] <[hidden email]>
To: IBM Netrexx <[hidden email]>
Sent: Fri Jun 10 21:00:19 2011
Subject: Re: [Ibm-netrexx] Java Byte Code (was netrexx site)

Oh, I always forget about the interpreter...

That one will get a lot more useful once the user code has not to go through the file system to parse classes.

isn't it sweet? now we c

2011/6/11 René Jansen <[hidden email]>

I agree, but we are not home free, even without byte code engineering, because we also have to take care of the incompatible class file formats that the new versions of javac produce. For example, for the 3.00 translator, we must be careful to produce the classfiles with the 1.4 flag; this never has been a problem before but now it does. This also implies there cannot be Java 5 calls used for generated Java source - now no problem but something we must remember very well. At the moment the translator is fully Java 1.1 compatible;  we might have to decide at some point that in order to support more modern Java features, the minimum level of Java that is required will increase. This must be part of the roadmap that we will put together.

René.

On Jun 11, 2011, at 12:58 AM, David Requena wrote:

Well, what it would automatically break is the warranty of getting compatible classes we have today. Going through javac assures no NetRexx generated code will yield non-compliant binary classes, event in the event of a NetRexxC bug.

More over, I still haven't heard any compelling reasons/advantages for such a switch..

2011/6/10 Kermit Kiser <[hidden email]>

I admit to being a little puzzled about why directly producing bytecode would break Java compatibility. I think the JVM verifies that the bytecode is legal and thus any such should be compatible.

Anyway, the advantages of producing bytecode that I see are that one could do NetRexx programming on a computer with the JRE and not have to require the JDK; also some ANT build files might be simplified. However, the important advantage of producing Java source code is to allow Java and NetRexx programmers to work together more easily. Granted, the two output forms are not mutually exclusive and the bytecode could easily be tested for differences.

-- Kermit

On 6/10/2011 1:40 PM, Thomas Schneider wrote:

When, and only when a NetRexx Compiler would directly emit BYTE-Code, it will NOT, at all, BREAK the Java inter-operability.

But this should be an option of the respective NetRexx compiler, IMHO.

Thomas.
========================================================
Am 10.06.2011 22:17, schrieb George Hovey:

Alan,

>>The day NetRexx stops doing this and goes directly to bytecode is the day I stop using NetRexx.

Hear, hear!   I have argued, no doubt ad nauseam, that compatibility with Java at the class level should be an essential claim of NetRexx, and be prominently asserted at the web site.  This would signal that Java and NetRexx development can be safely mixed and, IMO, act as a powerful attractant to Java programmers.  There has been some talk in this forum of emitting byte code.  Doing so would forever break that compact.
George

On Fri, Jun 10, 2011 at 2:39 PM, Alan Sampson <[hidden email]> wrote:

On 10 June 2011 11:21, George Hovey <[hidden email]> wrote:

Bob,
BTW, NetRexx is not a JVM language: it is a translator whose target language is Java source code.  Of course, the Java compiler then produces JVM code.  The crucial point is that this guarantees that NetRexx classes are totally compatible with Java classes.
George

Good point and one that should be stressed.   NetRexx's ability to generate Java source is a huge benefit when building complex projects as you can mix and match compilation units and just take the NetRexx generated source and merge it into the bigger "Java only" suite thus allowing developers to work in the environment they're most comfortable in.

The day NetRexx stops doing this and goes directly to bytecode is the day I stop using NetRexx.

A.



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

_______________________________________________
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 (www.thsitc.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/

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

--
Saludos / Regards,
David Requena

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

[ThSITC]

Hi Rene, thanks for that insight I didn't know.

I'm currenlty working with Java 7, however, for my personal tests.

Thomas.
============================================
Am 11.06.2011 03:10, schrieb Measel, Mike:

Provide a command line interpreter shell.

NRX>say "hello free world"

Hello free world.

---

From: [hidden email] [hidden email]
To: IBM Netrexx [hidden email]
Sent: Fri Jun 10 21:00:19 2011
Subject: Re: [Ibm-netrexx] Java Byte Code (was netrexx site)

Oh, I always forget about the interpreter...

That one will get a lot more useful once the user code has not to go through the file system to parse classes.

isn't it sweet? now we c

2011/6/11 René Jansen <[hidden email]>

I agree, but we are not home free, even without byte code engineering, because we also have to take care of the incompatible class file formats that the new versions of javac produce. For example, for the 3.00 translator, we must be careful to produce the classfiles with the 1.4 flag; this never has been a problem before but now it does. This also implies there cannot be Java 5 calls used for generated Java source - now no problem but something we must remember very well. At the moment the translator is fully Java 1.1 compatible;  we might have to decide at some point that in order to support more modern Java features, the minimum level of Java that is required will increase. This must be part of the roadmap that we will put together.

René.

On Jun 11, 2011, at 12:58 AM, David Requena wrote:

Well, what it would automatically break is the warranty of getting compatible classes we have today. Going through javac assures no NetRexx generated code will yield non-compliant binary classes, event in the event of a NetRexxC bug.

More over, I still haven't heard any compelling reasons/advantages for such a switch..

2011/6/10 Kermit Kiser <[hidden email]>

I admit to being a little puzzled about why directly producing bytecode would break Java compatibility. I think the JVM verifies that the bytecode is legal and thus any such should be compatible.

Anyway, the advantages of producing bytecode that I see are that one could do NetRexx programming on a computer with the JRE and not have to require the JDK; also some ANT build files might be simplified. However, the important advantage of producing Java source code is to allow Java and NetRexx programmers to work together more easily. Granted, the two output forms are not mutually exclusive and the bytecode could easily be tested for differences.

-- Kermit

On 6/10/2011 1:40 PM, Thomas Schneider wrote:

When, and only when a NetRexx Compiler would directly emit BYTE-Code, it will NOT, at all, BREAK the Java inter-operability.

But this should be an option of the respective NetRexx compiler, IMHO.

Thomas.
========================================================
Am 10.06.2011 22:17, schrieb George Hovey:

Alan,

>>The day NetRexx stops doing this and goes directly to bytecode is the day I stop using NetRexx.

Hear, hear!   I have argued, no doubt ad nauseam, that compatibility with Java at the class level should be an essential claim of NetRexx, and be prominently asserted at the web site.  This would signal that Java and NetRexx development can be safely mixed and, IMO, act as a powerful attractant to Java programmers.  There has been some talk in this forum of emitting byte code.  Doing so would forever break that compact.
George

On Fri, Jun 10, 2011 at 2:39 PM, Alan Sampson <[hidden email]> wrote:

On 10 June 2011 11:21, George Hovey <[hidden email]> wrote:

Bob,
BTW, NetRexx is not a JVM language: it is a translator whose target language is Java source code.  Of course, the Java compiler then produces JVM code.  The crucial point is that this guarantees that NetRexx classes are totally compatible with Java classes.
George

Good point and one that should be stressed.   NetRexx's ability to generate Java source is a huge benefit when building complex projects as you can mix and match compilation units and just take the NetRexx generated source and merge it into the bigger "Java only" suite thus allowing developers to work in the environment they're most comfortable in.

The day NetRexx stops doing this and goes directly to bytecode is the day I stop using NetRexx.

A.



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

_______________________________________________
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 (www.thsitc.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/

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

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

[David Requena]

Mike,

something very similar to this already exists. Lookup Martin Lapaix' excellent Workspace for NetRexx.

The fact remains that a file must be written to disk, then read and parsed in order to print your "hello free world"

2011/6/11 Measel, Mike <[hidden email]>

Provide a command line interpreter shell.

NRX>say "hello free world"

Hello free world.

---

From: [hidden email] <[hidden email]>
To: IBM Netrexx <[hidden email]>
Sent: Fri Jun 10 21:00:19 2011
Subject: Re: [Ibm-netrexx] Java Byte Code (was netrexx site)

Oh, I always forget about the interpreter...

That one will get a lot more useful once the user code has not to go through the file system to parse classes.

isn't it sweet? now we c

2011/6/11 René Jansen <[hidden email]>

I agree, but we are not home free, even without byte code engineering, because we also have to take care of the incompatible class file formats that the new versions of javac produce. For example, for the 3.00 translator, we must be careful to produce the classfiles with the 1.4 flag; this never has been a problem before but now it does. This also implies there cannot be Java 5 calls used for generated Java source - now no problem but something we must remember very well. At the moment the translator is fully Java 1.1 compatible;  we might have to decide at some point that in order to support more modern Java features, the minimum level of Java that is required will increase. This must be part of the roadmap that we will put together.

René.

On Jun 11, 2011, at 12:58 AM, David Requena wrote:

Well, what it would automatically break is the warranty of getting compatible classes we have today. Going through javac assures no NetRexx generated code will yield non-compliant binary classes, event in the event of a NetRexxC bug.

More over, I still haven't heard any compelling reasons/advantages for such a switch..

2011/6/10 Kermit Kiser <[hidden email]>

I admit to being a little puzzled about why directly producing bytecode would break Java compatibility. I think the JVM verifies that the bytecode is legal and thus any such should be compatible.

Anyway, the advantages of producing bytecode that I see are that one could do NetRexx programming on a computer with the JRE and not have to require the JDK; also some ANT build files might be simplified. However, the important advantage of producing Java source code is to allow Java and NetRexx programmers to work together more easily. Granted, the two output forms are not mutually exclusive and the bytecode could easily be tested for differences.

-- Kermit

On 6/10/2011 1:40 PM, Thomas Schneider wrote:

When, and only when a NetRexx Compiler would directly emit BYTE-Code, it will NOT, at all, BREAK the Java inter-operability.

But this should be an option of the respective NetRexx compiler, IMHO.

Thomas.
========================================================
Am 10.06.2011 22:17, schrieb George Hovey:

Alan,

>>The day NetRexx stops doing this and goes directly to bytecode is the day I stop using NetRexx.

Hear, hear!   I have argued, no doubt ad nauseam, that compatibility with Java at the class level should be an essential claim of NetRexx, and be prominently asserted at the web site.  This would signal that Java and NetRexx development can be safely mixed and, IMO, act as a powerful attractant to Java programmers.  There has been some talk in this forum of emitting byte code.  Doing so would forever break that compact.
George

On Fri, Jun 10, 2011 at 2:39 PM, Alan Sampson <[hidden email]> wrote:

On 10 June 2011 11:21, George Hovey <[hidden email]> wrote:

Bob,
BTW, NetRexx is not a JVM language: it is a translator whose target language is Java source code.  Of course, the Java compiler then produces JVM code.  The crucial point is that this guarantees that NetRexx classes are totally compatible with Java classes.
George

Good point and one that should be stressed.   NetRexx's ability to generate Java source is a huge benefit when building complex projects as you can mix and match compilation units and just take the NetRexx generated source and merge it into the bigger "Java only" suite thus allowing developers to work in the environment they're most comfortable in.

The day NetRexx stops doing this and goes directly to bytecode is the day I stop using NetRexx.

A.



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

_______________________________________________
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 (www.thsitc.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/

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

--
Saludos / Regards,
David Requena

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

[David Requena]

Mike,

something very similar to this already exists. Lookup Martin Lafaix' excellent Workspace for NetRexx.

That does not change the fact that 

2011/6/11 Measel, Mike <[hidden email]>

Provide a command line interpreter shell.

NRX>say "hello free world"

Hello free world.

---

From: [hidden email] <[hidden email]>
To: IBM Netrexx <[hidden email]>
Sent: Fri Jun 10 21:00:19 2011
Subject: Re: [Ibm-netrexx] Java Byte Code (was netrexx site)

Oh, I always forget about the interpreter...

That one will get a lot more useful once the user code has not to go through the file system to parse classes.

isn't it sweet? now we c

2011/6/11 René Jansen <[hidden email]>

I agree, but we are not home free, even without byte code engineering, because we also have to take care of the incompatible class file formats that the new versions of javac produce. For example, for the 3.00 translator, we must be careful to produce the classfiles with the 1.4 flag; this never has been a problem before but now it does. This also implies there cannot be Java 5 calls used for generated Java source - now no problem but something we must remember very well. At the moment the translator is fully Java 1.1 compatible;  we might have to decide at some point that in order to support more modern Java features, the minimum level of Java that is required will increase. This must be part of the roadmap that we will put together.

René.

On Jun 11, 2011, at 12:58 AM, David Requena wrote:

Well, what it would automatically break is the warranty of getting compatible classes we have today. Going through javac assures no NetRexx generated code will yield non-compliant binary classes, event in the event of a NetRexxC bug.

More over, I still haven't heard any compelling reasons/advantages for such a switch..

2011/6/10 Kermit Kiser <[hidden email]>

I admit to being a little puzzled about why directly producing bytecode would break Java compatibility. I think the JVM verifies that the bytecode is legal and thus any such should be compatible.

Anyway, the advantages of producing bytecode that I see are that one could do NetRexx programming on a computer with the JRE and not have to require the JDK; also some ANT build files might be simplified. However, the important advantage of producing Java source code is to allow Java and NetRexx programmers to work together more easily. Granted, the two output forms are not mutually exclusive and the bytecode could easily be tested for differences.

-- Kermit

On 6/10/2011 1:40 PM, Thomas Schneider wrote:

When, and only when a NetRexx Compiler would directly emit BYTE-Code, it will NOT, at all, BREAK the Java inter-operability.

But this should be an option of the respective NetRexx compiler, IMHO.

Thomas.
========================================================
Am 10.06.2011 22:17, schrieb George Hovey:

Alan,

>>The day NetRexx stops doing this and goes directly to bytecode is the day I stop using NetRexx.

Hear, hear!   I have argued, no doubt ad nauseam, that compatibility with Java at the class level should be an essential claim of NetRexx, and be prominently asserted at the web site.  This would signal that Java and NetRexx development can be safely mixed and, IMO, act as a powerful attractant to Java programmers.  There has been some talk in this forum of emitting byte code.  Doing so would forever break that compact.
George

On Fri, Jun 10, 2011 at 2:39 PM, Alan Sampson <[hidden email]> wrote:

On 10 June 2011 11:21, George Hovey <[hidden email]> wrote:

Bob,
BTW, NetRexx is not a JVM language: it is a translator whose target language is Java source code.  Of course, the Java compiler then produces JVM code.  The crucial point is that this guarantees that NetRexx classes are totally compatible with Java classes.
George

Good point and one that should be stressed.   NetRexx's ability to generate Java source is a huge benefit when building complex projects as you can mix and match compilation units and just take the NetRexx generated source and merge it into the bigger "Java only" suite thus allowing developers to work in the environment they're most comfortable in.

The day NetRexx stops doing this and goes directly to bytecode is the day I stop using NetRexx.

A.



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

_______________________________________________
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 (www.thsitc.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/

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

--
Saludos / Regards,
David Requena

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

[Robert L Hamilton]

The Red Book is, at best, a reference in IBM-ese and 'The Net Rexx Language' is long out-of-print, I'm afraid to report.  Online there is NetRexx 2 of 22nd May 2009 and Howard Fosdick's book has a chapter on Netrexx. There is also a book -- that I cannot locate -- that surverys all the various encarnations of REXX. But, I have yet to see a REXX book at Barnes & Noble or Borders.

 

Bob Hamilton

Richardson Texas USA

 

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

[Joe Niffen]

Thanks for the replies.
I have The NexRexx Language book here somewhere, even has Mike's autograph.

I asked him for it during the 2000 Phoenix Symposium and he graciously granted it.
Thanks again Mike.

Joe



On 6/11/2011 6:34 PM, Robert Hamilton wrote:

The Red Book is, at best, a reference in IBM-ese and 'The Net Rexx Language' is long out-of-print, I'm afraid to report.  Online there is NetRexx 2 of 22nd May 2009 and Howard Fosdick's book has a chapter on Netrexx. There is also a book -- that I cannot locate -- that surverys all the various encarnations of REXX. But, I have yet to see a REXX book at Barnes & Noble or Borders.

 

Bob Hamilton

Richardson Texas USA

 

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

[Fernando Cassia-2]

On Sat, Jun 11, 2011 at 20:34, Robert Hamilton <[hidden email]> wrote:
> The Red Book is, at best, a reference in IBM-ese and 'The Net Rexx Language'
> is long out-of-print, I'm afraid to report.


Amazon.com and Amazon UK both carry it, if you don´t mind getting a used copy

http://ho.io/NetRexxLang
http://p.sf.net/vbox-users/NetRexxUK

FC

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