Down the JAVA trail

[Mike Cowlishaw]

I find TNL ambivalent on the subject of generating bytecode directly rather than through the intermediary of javac.  Mike mentions considering doing so, but rejected that route because of incompatibilities with Java tools.  Would it have been his preferred choice?  I would very much like to hear our language giants discuss the pros and cons of removing javac from the chain.

I think I started off with the assumption that I would eventually generate bytecodes (.class  files) in the NetRexx compiler, but didn't partly because of the extra work (although I think the compiler is structured now so it would not be too hard).  But the main reason was as you cite: various tools that 'read' class files (and their bytecodes in particular) probably only handle sequences that javac emits, or might behave oddly with unusual sequences.  That's much less of a problem now because of the Reflection API is more complete (it might even be possible to remove the class-reading code in NetRexxC). 

 

On the other hand, much of the good performance of Java, now, is due to JITs -- and they would almost certainly produce less-good performance if confronted with unseen bytecode sequences.   (I may be maligning JITs, here -- it could be they are very general.)

 

On the plus side, avoiding the need for javac would improve speed and usability, as well as removing the dependency on the Java SDK and hence simplify installation.  However, it would increase the testing load .. one would still need to have the 'generate Java source' option, I think, so both that and the directly-generated bytecode would need testcases.  

 

Counter to that last argument is the possibility of doing things at the bytecode level that cannot be done using Java sourcecode.  But it would be a big step to drop Java sourcecode generation.

 

Mike

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Thomas.Schneider.Wien]

+ 1 vote for allowing the Java Syntax as well.
Thomas Schneider.
==================================================
Am 08.10.2010 18:44, schrieb Kermit Kiser:

+1 vote for Bob's request to enhance NetRexx to accept Java wildcard syntax on import statements. I never did understand why I have to remember a different and much less obvious syntax for that one.

-- Kermit

On 10/7/2010 11:10 PM, Robert Hamilton wrote:

thanks; I have the 22 May 2009 version and one earlier. The reason for my question: I don't know if I'm dealing with JAVA or NetRexx in jEdit. And, If NetRexx can deal with JAVA why can it not deal with the JAVA 'import' statement?

Thanks for you time and enjoy the day. . .

Bobh

 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

  

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Thomas.Schneider.Wien]

  Hello Chip & all,

I have been off-line for personal reasons for 5 days (no access to a
computer at all). I am just following the discussion on all the topics
*not* raised by me currently in a first in/first read manner.

I think we are too much currently focusing on the *when goes Mikes
NetRexx Compiler Open source* question too much.

I have been *not* aware from the work Quique did with his NetRexx GUI
samples, for instance.

My personal opinion is, that we should discuss the organizational issues
of www.NetRexx.org *now* (under the head of Rene Jansen, who is a very
experienced project leader).

The matters we should discuss should be:

1.) Which already existing *products* should be available for download
from www.netrexx.org.

2.) Which libraries ?

3.) which tutorials are available? which of them would need an update?

etc, etc. (please add the points you think would be needed/wanted)

We can start to discuss this *now*, and make a schedule for that *now*.

Thus, when the *open source* becomes available, all the other work
is already done, or at least some common sense and a work schedule does
already exist.

Thomas Schneider.

PS: I'm doing that in reply to Chip's comment, which is so good to read,
as always. In summary, let us not only concentrate on language features,
but let's put together all those useful pieces in a central and
organized way.

And let's do that *now*, so that we are ready when time comes ...
=============================================================

Am 09.10.2010 00:49, schrieb Chip Davis:

> My mother was not by nature a talented cook.  She depended on recipes
> from friends, relatives, books, magazines, and the occasional leak
> from a prestigious restaurant.  Unfortunately, she invariably modified
> the recipe somewhat from the original, regardless of its provenance.
>
> And the result was usually dismal.
>
> I can remember as a 12-year-old child, pleading with her to simply
> follow the recipe the first time.  Then, if that was successful, she
> could get creative and try to improve on the original.
>
> My mother came to mind as I see a theme developing on this forum:
>  1. Someone proposes an "improvement" to NetRexx.
>  2. Much healthy discussion ensues.
>  3. Mike finally weighs in with the 12 perfectly good reasons why he
> did it the way that he did.
>  4. Most folks agree that they had not considered all of the factors,
> that Mike was right all along, and we should leave well enough alone.
>
> We do not yet have access to the NetRexx source code, and when we do
> get it we will need to do a fair amount of organizational work to make
> it "open" and available to everyone.  There will be change management
> processes to establish, teams to populate, build machines to create,
> documentation to update, copyright notices to change, etc., etc., etc.
>
> Given that all this work will be done by volunteers (with real jobs,
> usually) I don't expect (or want) to see any significant change to
> NetRexx in its first year.  As for bug fixes, I've been a member of
> this list since its inception; we went a very long time before the
> first legitimate bug was identified; I don't recall any after that. (I
> suspect that you could count them on one hand and still have enough
> fingers left over with which to properly salute Java-the-language in
> whatever cultural gesture you prefer. ;-)
>
> My primary point is (as it was to my mother) *don't change anything
> until you truly understand how it was intended to work*.  Then you
> will have a base from which to make knowledgeable updates.
>
> Then, with full involvement of the "Open NetRexx Community", decisions
> can be made regarding where to direct efforts to enhance NetRexx.  I
> agree that Java class interoperability is a far more significant
> concern than whether or not the 'import' or assignment statements
> should match Java's.  But the decision should be the stakeholders' and
> at the moment we are still building the "Open NetRexx Community".
>
> Please do not take this to mean that I am trying to suppress a full
> and rousing discussion of NetRexx and ways in which it could be
> improved.  All such ideas will are being archived and will be
> available when the time comes to consider enhancements.  Bring 'em on.
>
> But right now, what we really need are bullet- and idiot-proof
> installation routines for NetRexx and its various editor/IDE/plugins
> on a slew of different platforms.
>
> We need a true "NetRexx Users Guide" as a companion volume to Mike's
> TNL reference.  It will answer all the "why" and "when" questions that
>  every beginner has.
>
> We need MANY more examples.
>
> In twenty years of teaching programming languages, I've found that you
> hook students with examples of useful code, which you then use to
> explicate the underlying syntax, grammar, and features.  And yes, my
> first NetRexx course used a side-by-side comparison of a (pre-SWING)
> Java GUI app and its NetRexx equivalent.  I had to back up quite a
> ways to cover everything that was involved to make that code work, but
> by then they were motivated to learn how.  Most folks feel that if
> they had a couple of clear examples of code doing something akin to
> what they need, they could figure out how to make it do what they
> want.  It's not the most efficient way of learning (many of my
> students are self-taught, then come to me to learn what they missed)
> but few are truly capable of learning it from a book.
>
> So who wants to start collecting code for the "NetRexx By Example"
> repository?
>
> -Chip-
>
> On 10/8/10 20:02 George Hovey said:
>> I am certainly happy with NetRexx the way it is  -- I've used it for
>> ten years -- but I worry about progressively losing Java
>> interoperability at the class level, which I think is an important
>> element in attracting others to NetRexx.  David Requena says this has
>> already happened.
>>
>> On Fri, Oct 8, 2010 at 3:47 PM, Tom Maynard <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>      On 10/8/2010 2:11 PM, Robert Hamilton wrote:
>>
>>         I go for leaving NetRexx 2 as it was in 22 May 2009 description
>>         -- PERIOD.  except any bug fixes, of course.
>>
>>     Or emulate Donald Knuth and freeze the version number at something
>>     like Euler's constant or the Golden Ratio.
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
>
>

--
Thomas Schneider Projects ReyC & LOGOS on www.KENAI.com
_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Thomas.Schneider.Wien]

May I vote for wiki.netrexx.org, too ??
Thomas Schneider.

... *and*, following my answer to Chips comment:

What does prevent us (if that's the correct english term) to start this wiki now ?
Thomas.
==========================================================
Am 09.10.2010 12:48, schrieb David Requena:

Agreed. My vote goes to http://wiki.netrexx.org

El 09/10/2010 3:03, Jeff Hennick escribió:

 I'm thinking it is time for a Wiki, rather than a news-list-group organization, for these topics.  Unless there is some all-thoughtful person with lots of time who wishes to be "moderator."

On 10/8/2010 8:46 PM, George Hovey wrote:

That sounds right to me.  How about some kind of rough organization of the effort, eg a separate thread to discuss just the installation issue, that doesn't meander off in other directions?  It might have a title that clearly implies this, like "Please, NetRexx Installation Issues ONLY".

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[billfen]

On 10/9/2010 5:44 PM, Bruce Skelly wrote:
> Negotiation is a loose term.  IBM 100% owns NetRexx.  They can do
anything they want with it.  RexxLA is not offering to buy NetRexx, nor
offer IBM any sort of quid pro quo arrangement.  Since nothing of value is
being given to IBM, and nothing of value is being taken from RexxLA, I
don't see that there is a conflict.
>
> René is guiding NetRexx through all the obstacles at IBM to getting
release as open source.  Since this is not a billable project within IBM,
you are counting on a lot of people to give their free time to our benefit.
>
> I don't know the exact process, but I bet it involves reviewing all of
the code to make sure that IBM does in fact own the code, that the code is
free from any other restrictions, such as copyright, patent, or trade
secret.  There is probably a legal review that is under taken.
>
> If I remember correctly when IBM open sourced Object Rexx, we didn't get
part of it because it was encumbered by copyrights that belonged to other
companies.
>
> Bruce


The slides for Virgil Hein's presentation at the May, 2009 RexxLA Symposium
are available on the web.  These slides are (in theory) for RexxLA members
only, but they are readily accessible - I found them through google.  They
provide an outline of at least part of the IBM OSSC process.

(The 5 Meg PDF file is at:
http://www.rexxla.org/events/2009/presentations/02_Tuesday/Tue_Session_2/Net
Rexx%20for%20REXX%20LA%20051909.pdf )

It appears to me that the quid pro quo is that IBM provides the source to
RexxLA, and RexxLA must provide a plan to administer the open source (and
of course follow through on that plan).  The only reasonable conclusion I
can think of is that RexxLA has not yet provided a satisfactory plan or is
unable to commit the resources to administer it.  Based on the OORexx
support, it is obviously a lot of work.  Another possibility is that IBM
has actually changed its mind and is trying to renege on the commitment to
open source, but I seriously doubt that is the case.

As for the source ownership, I think there is almost no chance that is an
issue.  When I released IBM Employee Written Software back in the early
90's, if I recall correctly, part of the process included certifying
authorship.  I have no doubt (but no direct knowledge) that Mike certified
that he was the sole author of the NetRexx translator well before he
retired.

It is unfortunate that there was no RexxLA Symposium in 2010 to tell the
world (or at least the members :) what progress was made.  Outsiders can
only speculate on what has and has not been done in the year and a half
since the 2009 Symposium.

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



_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[George Hovey-2]

Mike, this was very helpful.  I have one further issue for your consideration.  My question about javac was prompted by a nebulous idea that has been on my mind; I would like to expound it in the hope that you will either encourage it or put it to rest.

Some may have noticed that I harp on maintaining Java interoperability (though its existence right now seems to be in some doubt).  This is partly because I feel that NetRexx has a natural constituency in programmers currently writing in Java (I assume that we all want NetRexx to spread and thrive in any and all directions).  I am not saying that Java programmers are in any way to be preferred to others who might be attracted  -- NetRexx should be a "big tent" -- just that they are "low hanging fruit".  Further, non-Java programmers are not second class citizens in NetRexx.  A vast category of programs can be written without ever (knowingly) invoking a Java class, and this will only improve if more Rexx features can be incorporated.  And even those wishing to exploit the Java Class Library don't need to know the Java language per se, but just conventions used in describing and invoking the library.

I made the switch to Java technology at a small software development firm which tried Java at the instigation of a talented, thoughtful and experienced programmer (not me).  He did this by prototyping a system for a bid at a speed management had never seen.  This won the bid and permission to form a group to fulfill the contract using Java.  I jumped at the chance to join and was quickly won over (as was the company, which presently stipulated that all future development would be done in Java) by the speed and relative painlessness of java development.

At about the same time I encountered NetRexx.  I noticed it because of positive experiences with Rexx under OS/2 (I especially liked the Rexx-extensible editor).  I vowed that if I ever returned to my preferred mode of employment, sole software cook and bottle washer for a scientific research group, NetRexx would be my development language.  This eventually came to pass.

I never even mentioned NetRexx to my employers as it was clearly a nonstarter from their standpoint.  But I also had a blind spot: I thought of it as an either/or choice --  you either developed in NetRexx or in Java.  But why not have mixed Java and NetRexx as an option?  Then forward looking programmers in organizations using Java could go to their managers and say "I've found a language that improves the Java development process.  It is totally interoperable with Java, but significantly simplifies coding.  It has some powerful intrinsic features not present in Java, and as a bonus, reduces carpal tunnel syndrome.  Furthermore you don't need to bet the farm on it.  It can be introduced in small doses to the current code base while we gain confidence in it."  In my dreams, time passes and one day a programmers asks "why not make NetRexx our standard language?  We still have full access to our company library, it will reduce development costs and ..."  Later, many more would email their bosses "I've been reading about this NetRexx phenomenon and here's some UTube links.  I know these people sound like fanatics but ..."

Hence my original question about javac.  I am not a computer scientist or language maven, but it seems to be, to a degree I only dimly understand, a guarantor of java compatibility.  But to attract Java developers, we have to offer some kind of contract analogous in strength and clarity to "100% pure Java".  I suppose we would also have to "keep up" with Java on certain source features in order to avoid deteriorating relations with Java programmers.  This could be problematical considering that we have no control over Java's direction.

Sorry for the long winded preamble.  The bottom line -- I'd appreciate a candid assessment of these ideas.

On Sun, Oct 10, 2010 at 2:16 AM, Mike Cowlishaw <[hidden email]> wrote:

I find TNL ambivalent on the subject of generating bytecode directly rather than through the intermediary of javac.  Mike mentions considering doing so, but rejected that route because of incompatibilities with Java tools.  Would it have been his preferred choice?  I would very much like to hear our language giants discuss the pros and cons of removing javac from the chain.

I think I started off with the assumption that I would eventually generate bytecodes (.class  files) in the NetRexx compiler, but didn't partly because of the extra work (although I think the compiler is structured now so it would not be too hard).  But the main reason was as you cite: various tools that 'read' class files (and their bytecodes in particular) probably only handle sequences that javac emits, or might behave oddly with unusual sequences.  That's much less of a problem now because of the Reflection API is more complete (it might even be possible to remove the class-reading code in NetRexxC). 

 

On the other hand, much of the good performance of Java, now, is due to JITs -- and they would almost certainly produce less-good performance if confronted with unseen bytecode sequences.   (I may be maligning JITs, here -- it could be they are very general.)

 

On the plus side, avoiding the need for javac would improve speed and usability, as well as removing the dependency on the Java SDK and hence simplify installation.  However, it would increase the testing load .. one would still need to have the 'generate Java source' option, I think, so both that and the directly-generated bytecode would need testcases.  

 

Counter to that last argument is the possibility of doing things at the bytecode level that cannot be done using Java sourcecode.  But it would be a big step to drop Java sourcecode generation.

 

Mike

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Aviatrexx]

On 10/10/10 19:12 [hidden email] said:
>
> The slides for Virgil Hein's presentation at the May, 2009 RexxLA Symposium
> are available on the web.  These slides are (in theory) for RexxLA members
> only, but they are readily accessible

The RexxLA policy is that Rexx Symposium materials are exclusively
available to RexxLA members for one year after the Symposium in which
they were presented.  After that time, they are available to everyone.

> It appears to me that the quid pro quo is that IBM provides the source to
> RexxLA, and RexxLA must provide a plan to administer the open source (and
> of course follow through on that plan).

And you would be correct.  But that quid pro quo is not negotiable,
and as RexxLA is a non-profit organization and René is an unpaid
officer, it would be hard to tease out a conflict of interest there.
In fact, one could easily argue that his interest, expertise, and
current IBM employment are advantages.

> The only reasonable conclusion I
> can think of is that RexxLA has not yet provided a satisfactory plan or is
> unable to commit the resources to administer it.

Well, reasonableness tends to be a very subjective measure.  From what
I understand (and I am not privy to any more than anyone else, see
Virgil's presentation) RexxLA has committed in writing to a plan that
meets IBM's objectives, and to providing the resources necessary to
execute that plan.  Had that not been the case, our application would
not have made it this far.

> Based on the OORexx
> support, it is obviously a lot of work.

True.  We knew that from the outset, but the opportunity was too good
to pass up.  Besides, the alternative (letting Object REXX languish in
obscurity in an IBM-proprietary vault) was unacceptable to many of us.

> Another possibility is that IBM
> has actually changed its mind and is trying to renege on the commitment to
> open source, but I seriously doubt that is the case.

To conclude that IBM has decided to renege on the arrangement would be
to assume that something had changed and that they were not telling us
of their decision for some reason.  (They don't want to hurt our
feelings?)  It's always quicker and easier to say "No".  It's much
more difficult and time-consuming to work through all the problems so
you can say "Yes".

Consider that IBM, like nearly every other company in this economy, is
having to do more with less.  I know that most of my IBM contacts are
now also doing the work of two or three of their colleagues who are no
longer IBM employees.  As has been noted, a pro-bono project such as
this cannot have a high priority in such an environment.

> It is unfortunate that there was no RexxLA Symposium in 2010 to tell the
> world (or at least the members :) what progress was made.  Outsiders can
> only speculate on what has and has not been done in the year and a half
> since the 2009 Symposium.

If by "outsiders" you mean "those who have not signed that NDA", I
doubt that there would have been much that could have been legally
shared.  As for their speculations, in the absence of knowledge one
way or the other, I tend to seek the counsel of Friar Ockham.

Yes, it is a shame that we were able to string together only 20 years
worth of Rexx Symposiums.  It was also miracle that we did.  Everyone
wants to be a guest; only the truly selfless volunteer to host.

-Chip-


_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[measel]

George, I know you are talking to MC but let me offer some real world observations on bytecode, and why I think the way nrx works now is just fine.

 

The company I work for started back in ’00 offering a java performance tool that worked by means of bytecode insertion. 

 

At that time we were unique and cozy with big blue services because we could find problems quickly, but whenever our name appeared in a thread dump we were also a target of support.  And our name appeared a lot since we can insert ourselves into each and every method.

 

Along the way, we bounced off of things like AspectJ and again were often accused of being a problem although we usually exposed the developer in the end.  Btw, we work fine with AspectJ and others if they play by the rules (JSR 163).

 

All this to say, STAY AWAY from the bytecodes and conform to the java rules and use the java tools and all will be good.  And go forth and multiply ( n = n * 1) and yeah all that.

 

(jython and jruby both work the way NetRexx does today)

 

Oh, and you can see the cute little byte codes like this:   (  my previous example the Trexx.class)

 

javap -c Trexx > Trexx.bc

more Trexx.bc

Compiled from "Trexx.nrx"

public class Trexx extends java.lang.Object{

static {};

  Code:

   0:         new       #9; //class netrexx/lang/Rexx

   3:         dup

   4:         iconst_1

   5:         invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   8:         putstatic              #11; //Field $01:Lnetrexx/lang/Rexx;

   11:       return

 

public Trexx();

  Code:

   0:         aload_0

   1:         invokespecial     #13; //Method java/lang/Object."<init>":()V

   4:         aload_0

   5:         invokevirtual      #21; //Method dostuff:()V

   8:         return

 

public void dostuff();

  Code:

   0:         new       #9; //class netrexx/lang/Rexx

   3:         dup

   4:         iconst_0

   5:         invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   8:         astore_1

   9:         new       #9; //class netrexx/lang/Rexx

   12:       dup

   13:       sipush   1000

   16:       invokespecial     #16; //Method netrexx/lang/Rexx."<init>":(S)V

   19:       astore_2

   20:       ldc          #3; //String increment rexx

   22:       invokestatic        #19; //Method netrexx/lang/RexxIO.Say:(Ljava/lang/String;)Z

   25:       pop

   26:       aload_1

   27:       aconst_null

   28:       aload_2

   29:       invokevirtual      #18; //Method netrexx/lang/Rexx.OpLt:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Z

   32:       ifeq        44

   35:       aload_0

   36:       aload_1

   37:       invokevirtual      #22; //Method increment:(Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   40:       astore_1

   41:       goto       26

   44:       aload_1

   45:       invokestatic        #20; //Method netrexx/lang/RexxIO.Say:(Lnetrexx/lang/Rexx;)Z

   48:       pop

   49:       ldc          #2; //String increment integer

   51:       invokestatic        #19; //Method netrexx/lang/RexxIO.Say:(Ljava/lang/String;)Z

   54:       pop

   55:       new       #9; //class netrexx/lang/Rexx

   58:       dup

   59:       new       #9; //class netrexx/lang/Rexx

   62:       dup

   63:       iconst_0

   64:       invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   67:       invokevirtual      #26; //Method netrexx/lang/Rexx.toint:()I

   70:       invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   73:       astore_1

   74:       new       #9; //class netrexx/lang/Rexx

   77:       dup

   78:       sipush   1000

   81:       invokespecial     #16; //Method netrexx/lang/Rexx."<init>":(S)V

   84:       astore_2

   85:       aload_1

   86:       aconst_null

   87:       aload_2

   88:       invokevirtual      #18; //Method netrexx/lang/Rexx.OpLt:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Z

   91:       ifeq        103

   94:       aload_0

   95:       aload_1

   96:       invokevirtual      #22; //Method increment:(Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   99:       astore_1

   100:     goto       85

   103:     aload_1

   104:     invokestatic        #20; //Method netrexx/lang/RexxIO.Say:(Lnetrexx/lang/Rexx;)Z

   107:     pop

   108:     ldc          #4; //String increment string

   110:     invokestatic        #19; //Method netrexx/lang/RexxIO.Say:(Ljava/lang/String;)Z

   113:     pop

   114:     new       #9; //class netrexx/lang/Rexx

   117:     dup

   118:     bipush  48

   120:     invokespecial     #14; //Method netrexx/lang/Rexx."<init>":(C)V

   123:     invokestatic        #25; //Method netrexx/lang/Rexx.toString:(Lnetrexx/lang/Rexx;)Ljava/lang/String;

   126:     invokestatic        #24; //Method netrexx/lang/Rexx.toRexx:(Ljava/lang/String;)Lnetrexx/lang/Rexx;

   129:     astore_1

   130:     new       #9; //class netrexx/lang/Rexx

   133:     dup

   134:     sipush   1000

   137:     invokespecial     #16; //Method netrexx/lang/Rexx."<init>":(S)V

   140:     astore_2

   141:     aload_1

   142:     aconst_null

   143:     aload_2

   144:     invokevirtual      #18; //Method netrexx/lang/Rexx.OpLt:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Z

   147:     ifeq        159

   150:     aload_0

   151:     aload_1

   152:     invokevirtual      #22; //Method increment:(Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   155:     astore_1

   156:     goto       141

   159:     aload_1

   160:     invokestatic        #20; //Method netrexx/lang/RexxIO.Say:(Lnetrexx/lang/Rexx;)Z

   163:     pop

   164:     return

 

public int increment(int);

  Code:

   0:         new       #9; //class netrexx/lang/Rexx

   3:         dup

   4:         iload_1

   5:         invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   8:         aconst_null

   9:         getstatic               #11; //Field $01:Lnetrexx/lang/Rexx;

   12:       invokevirtual      #17; //Method netrexx/lang/Rexx.OpAdd:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   15:       invokevirtual      #26; //Method netrexx/lang/Rexx.toint:()I

   18:       ireturn

 

public java.lang.String increment(java.lang.String);

  Code:

   0:         iconst_0

   1:         istore_2

   2:         aload_1

   3:         invokevirtual      #27; //Method java/lang/String.trim:()Ljava/lang/String;

   6:         invokestatic        #23; //Method java/lang/Integer.parseInt:(Ljava/lang/String;)I

   9:         istore_2

   10:       new       #9; //class netrexx/lang/Rexx

   13:       dup

   14:       iload_2

   15:       invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   18:       aconst_null

   19:       getstatic               #11; //Field $01:Lnetrexx/lang/Rexx;

   22:       invokevirtual      #17; //Method netrexx/lang/Rexx.OpAdd:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   25:       invokestatic        #25; //Method netrexx/lang/Rexx.toString:(Lnetrexx/lang/Rexx;)Ljava/lang/String;

   28:       areturn

 

public netrexx.lang.Rexx increment(netrexx.lang.Rexx);

  Code:

   0:         aload_1

   1:         aconst_null

   2:         getstatic               #11; //Field $01:Lnetrexx/lang/Rexx;

   5:         invokevirtual      #17; //Method netrexx/lang/Rexx.OpAdd:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   8:         areturn

 

public static void main(java.lang.String[]);

  Code:

   0:         new       #5; //class Trexx

   3:         invokespecial     #12; //Method "<init>":()V

   6:         return

 

}

 

<whatageek>In the old days we used to disassemble cobol and see which statements produced more instructions.<whatageek>

 

Good article about why programmers should understand bytecode:

 

http://www.ibm.com/developerworks/ibm/library/it-haggar_bytecode/

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of George Hovey
Sent: Sunday, October 10, 2010 2:56 PM
To: IBM Netrexx
Subject: Re: On RexxLA and NetRexx (WAS: Re: [Ibm-netrexx] Down the JAVA trail)

 

Mike, this was very helpful.  I have one further issue for your consideration.  My question about javac was prompted by a nebulous idea that has been on my mind; I would like to expound it in the hope that you will either encourage it or put it to rest.

….

 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[rvjansen]

<base href="x-msg://892/">Mike,

thanks for your interesting post. I would like to point out some things to think about. Your general proposition is that we should not needlessly occupy ourselves with bytecode because it might introduce support issues, and that I can agree with. But I would like to draw your attention to several issues here:

- the interpreter part of NetRexx already 'mucks' with bytecode and classloaders because it needs to

- jruby (at least - I am not that into Jython) needs bytecode manipulation, to the effect that Charles Nutter did write a bytecode assembler integrated into JRuby for this purpose

- the new calls for dynamic invocation 'invokedynamic' and tail recursion in Java 7 mlvm (multi-language virtual machine) do not have Java syntax elements dedicated to them

This last item means that all research into dynamic methods, like ooRexx has, needs to be done in bytecode

The article where the posted link points to is interesting but quite dated; the Java VM world in the Hotspot era is quite different and the compiler and VM optimize a lot more than the article states; this still does not inlfuence your main proposition however. I also think it is wise to leverage higher level compilers; if we choose these meticulously, we might end up with a lot of platforms to run NetRexx on, well into the future.

best regards,

René Jansen.

On 13 okt 2010, at 13:21, Measel, Mike wrote:

George, I know you are talking to MC but let me offer some real world observations on bytecode, and why I think the way nrx works now is just fine.

 

The company I work for started back in ’00 offering a java performance tool that worked by means of bytecode insertion. 

 

At that time we were unique and cozy with big blue services because we could find problems quickly, but whenever our name appeared in a thread dump we were also a target of support.  And our name appeared a lot since we can insert ourselves into each and every method.

 

Along the way, we bounced off of things like AspectJ and again were often accused of being a problem although we usually exposed the developer in the end.  Btw, we work fine with AspectJ and others if they play by the rules (JSR 163).

 

All this to say, STAY AWAY from the bytecodes and conform to the java rules and use the java tools and all will be good.  And go forth and multiply ( n = n * 1) and yeah all that.

 

(jython and jruby both work the way NetRexx does today)

 

Oh, and you can see the cute little byte codes like this:   (  my previous example the Trexx.class)

 

javap -c Trexx > Trexx.bc

more Trexx.bc

Compiled from "Trexx.nrx"

public class Trexx extends java.lang.Object{

static {};

  Code:

   0:         new       #9; //class netrexx/lang/Rexx

   3:         dup

   4:         iconst_1

   5:         invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   8:         putstatic              #11; //Field $01:Lnetrexx/lang/Rexx;

   11:       return

 

public Trexx();

  Code:

   0:         aload_0

   1:         invokespecial     #13; //Method java/lang/Object."<init>":()V

   4:         aload_0

   5:         invokevirtual      #21; //Method dostuff:()V

   8:         return

 

public void dostuff();

  Code:

   0:         new       #9; //class netrexx/lang/Rexx

   3:         dup

   4:         iconst_0

   5:         invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   8:         astore_1

   9:         new       #9; //class netrexx/lang/Rexx

   12:       dup

   13:       sipush   1000

   16:       invokespecial     #16; //Method netrexx/lang/Rexx."<init>":(S)V

   19:       astore_2

   20:       ldc          #3; //String increment rexx

   22:       invokestatic        #19; //Method netrexx/lang/RexxIO.Say:(Ljava/lang/String;)Z

   25:       pop

   26:       aload_1

   27:       aconst_null

   28:       aload_2

   29:       invokevirtual      #18; //Method netrexx/lang/Rexx.OpLt:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Z

   32:       ifeq        44

   35:       aload_0

   36:       aload_1

   37:       invokevirtual      #22; //Method increment:(Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   40:       astore_1

   41:       goto       26

   44:       aload_1

   45:       invokestatic        #20; //Method netrexx/lang/RexxIO.Say:(Lnetrexx/lang/Rexx;)Z

   48:       pop

   49:       ldc          #2; //String increment integer

   51:       invokestatic        #19; //Method netrexx/lang/RexxIO.Say:(Ljava/lang/String;)Z

   54:       pop

   55:       new       #9; //class netrexx/lang/Rexx

   58:       dup

   59:       new       #9; //class netrexx/lang/Rexx

   62:       dup

   63:       iconst_0

   64:       invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   67:       invokevirtual      #26; //Method netrexx/lang/Rexx.toint:()I

   70:       invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   73:       astore_1

   74:       new       #9; //class netrexx/lang/Rexx

   77:       dup

   78:       sipush   1000

   81:       invokespecial     #16; //Method netrexx/lang/Rexx."<init>":(S)V

   84:       astore_2

   85:       aload_1

   86:       aconst_null

   87:       aload_2

   88:       invokevirtual      #18; //Method netrexx/lang/Rexx.OpLt:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Z

   91:       ifeq        103

   94:       aload_0

   95:       aload_1

   96:       invokevirtual      #22; //Method increment:(Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   99:       astore_1

   100:     goto       85

   103:     aload_1

   104:     invokestatic        #20; //Method netrexx/lang/RexxIO.Say:(Lnetrexx/lang/Rexx;)Z

   107:     pop

   108:     ldc          #4; //String increment string

   110:     invokestatic        #19; //Method netrexx/lang/RexxIO.Say:(Ljava/lang/String;)Z

   113:     pop

   114:     new       #9; //class netrexx/lang/Rexx

   117:     dup

   118:     bipush  48

   120:     invokespecial     #14; //Method netrexx/lang/Rexx."<init>":(C)V

   123:     invokestatic        #25; //Method netrexx/lang/Rexx.toString:(Lnetrexx/lang/Rexx;)Ljava/lang/String;

   126:     invokestatic        #24; //Method netrexx/lang/Rexx.toRexx:(Ljava/lang/String;)Lnetrexx/lang/Rexx;

   129:     astore_1

   130:     new       #9; //class netrexx/lang/Rexx

   133:     dup

   134:     sipush   1000

   137:     invokespecial     #16; //Method netrexx/lang/Rexx."<init>":(S)V

   140:     astore_2

   141:     aload_1

   142:     aconst_null

   143:     aload_2

   144:     invokevirtual      #18; //Method netrexx/lang/Rexx.OpLt:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Z

   147:     ifeq        159

   150:     aload_0

   151:     aload_1

   152:     invokevirtual      #22; //Method increment:(Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   155:     astore_1

   156:     goto       141

   159:     aload_1

   160:     invokestatic        #20; //Method netrexx/lang/RexxIO.Say:(Lnetrexx/lang/Rexx;)Z

   163:     pop

   164:     return

 

public int increment(int);

  Code:

   0:         new       #9; //class netrexx/lang/Rexx

   3:         dup

   4:         iload_1

   5:         invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   8:         aconst_null

   9:         getstatic               #11; //Field $01:Lnetrexx/lang/Rexx;

   12:       invokevirtual      #17; //Method netrexx/lang/Rexx.OpAdd:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   15:       invokevirtual      #26; //Method netrexx/lang/Rexx.toint:()I

   18:       ireturn

 

public java.lang.String increment(java.lang.String);

  Code:

   0:         iconst_0

   1:         istore_2

   2:         aload_1

   3:         invokevirtual      #27; //Method java/lang/String.trim:()Ljava/lang/String;

   6:         invokestatic        #23; //Method java/lang/Integer.parseInt:(Ljava/lang/String;)I

   9:         istore_2

   10:       new       #9; //class netrexx/lang/Rexx

   13:       dup

   14:       iload_2

   15:       invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   18:       aconst_null

   19:       getstatic               #11; //Field $01:Lnetrexx/lang/Rexx;

   22:       invokevirtual      #17; //Method netrexx/lang/Rexx.OpAdd:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   25:       invokestatic        #25; //Method netrexx/lang/Rexx.toString:(Lnetrexx/lang/Rexx;)Ljava/lang/String;

   28:       areturn

 

public netrexx.lang.Rexx increment(netrexx.lang.Rexx);

  Code:

   0:         aload_1

   1:         aconst_null

   2:         getstatic               #11; //Field $01:Lnetrexx/lang/Rexx;

   5:         invokevirtual      #17; //Method netrexx/lang/Rexx.OpAdd:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   8:         areturn

 

public static void main(java.lang.String[]);

  Code:

   0:         new       #5; //class Trexx

   3:         invokespecial     #12; //Method "<init>":()V

   6:         return

 

}

 

<whatageek>In the old days we used to disassemble cobol and see which statements produced more instructions.<whatageek>

 

Good article about why programmers should understand bytecode:

 

http://www.ibm.com/developerworks/ibm/library/it-haggar_bytecode/

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of George Hovey
Sent: Sunday, October 10, 2010 2:56 PM
To: IBM Netrexx
Subject: Re: On RexxLA and NetRexx (WAS: Re: [Ibm-netrexx] Down the JAVA trail)

 

Mike, this was very helpful.  I have one further issue for your consideration.  My question about javac was prompted by a nebulous idea that has been on my mind; I would like to expound it in the hope that you will either encourage it or put it to rest.

….

 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Thomas.Schneider.Wien]

  Hello Chip,
    thanks for the insights....

I am offering, again, to help in the NetRexx Project as far as I can.

I'm fascinated from the language design, and willing to support it (as
I'm already in pension).

I think, however, that ooRexx and NetRexx discussions should be splitted,
having an OWN NetRexx group, which I think should be OPEN.

Also, putting the OPEN source of NetRexx on www.KENAI.com would give
NetRexx an instant *visibility* to the Java minded people. As far as I
can remember, some 50.000 very knowledgable individuals/companies are a
member of www.KENAI.com with various Java related projects.

Far more, as any *own NetRexx* activity can build up quickly....

As far as I got the rules, www.KENAI.com has a very excelennt *standard*
Project scheme we could simply re-use, thus avoiding all the hassles
to build everything up again from scratch ...

Comments will be welcome... :-)

Thomas Schneider.
=============================================================

Am 11.10.2010 00:27, schrieb Chip Davis:

> On 10/10/10 19:12 [hidden email] said:
>>
>> The slides for Virgil Hein's presentation at the May, 2009 RexxLA
>> Symposium
>> are available on the web.  These slides are (in theory) for RexxLA
>> members
>> only, but they are readily accessible
>
> The RexxLA policy is that Rexx Symposium materials are exclusively
> available to RexxLA members for one year after the Symposium in which
> they were presented.  After that time, they are available to everyone.
>
>> It appears to me that the quid pro quo is that IBM provides the
>> source to
>> RexxLA, and RexxLA must provide a plan to administer the open source
>> (and
>> of course follow through on that plan).
>
> And you would be correct.  But that quid pro quo is not negotiable,
> and as RexxLA is a non-profit organization and René is an unpaid
> officer, it would be hard to tease out a conflict of interest there.
> In fact, one could easily argue that his interest, expertise, and
> current IBM employment are advantages.
>
>> The only reasonable conclusion I
>> can think of is that RexxLA has not yet provided a satisfactory plan
>> or is
>> unable to commit the resources to administer it.
>
> Well, reasonableness tends to be a very subjective measure.  From what
> I understand (and I am not privy to any more than anyone else, see
> Virgil's presentation) RexxLA has committed in writing to a plan that
> meets IBM's objectives, and to providing the resources necessary to
> execute that plan.  Had that not been the case, our application would
> not have made it this far.
>
>> Based on the OORexx
>> support, it is obviously a lot of work.
>
> True.  We knew that from the outset, but the opportunity was too good
> to pass up.  Besides, the alternative (letting Object REXX languish in
> obscurity in an IBM-proprietary vault) was unacceptable to many of us.
>
>> Another possibility is that IBM
>> has actually changed its mind and is trying to renege on the
>> commitment to
>> open source, but I seriously doubt that is the case.
>
> To conclude that IBM has decided to renege on the arrangement would be
> to assume that something had changed and that they were not telling us
> of their decision for some reason.  (They don't want to hurt our
> feelings?)  It's always quicker and easier to say "No".  It's much
> more difficult and time-consuming to work through all the problems so
> you can say "Yes".
>
> Consider that IBM, like nearly every other company in this economy, is
> having to do more with less.  I know that most of my IBM contacts are
> now also doing the work of two or three of their colleagues who are no
> longer IBM employees.  As has been noted, a pro-bono project such as
> this cannot have a high priority in such an environment.
>
>> It is unfortunate that there was no RexxLA Symposium in 2010 to tell the
>> world (or at least the members :) what progress was made.  Outsiders can
>> only speculate on what has and has not been done in the year and a half
>> since the 2009 Symposium.
>
> If by "outsiders" you mean "those who have not signed that NDA", I
> doubt that there would have been much that could have been legally
> shared.  As for their speculations, in the absence of knowledge one
> way or the other, I tend to seek the counsel of Friar Ockham.
>
> Yes, it is a shame that we were able to string together only 20 years
> worth of Rexx Symposiums.  It was also miracle that we did.  Everyone
> wants to be a guest; only the truly selfless volunteer to host.
>
> -Chip-
>
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
>
>

--
Thomas Schneider Projects ReyC & LOGOS on www.KENAI.com
_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[rvjansen]

Tom,

for your information, ooRexx also has discussion groups that are open to everyone that registers, at SourceForge.

best regards,

René.

On 13 okt 2010, at 14:54, Thomas Schneider wrote:

> Hello Chip,
>   thanks for the insights....
>
> I am offering, again, to help in the NetRexx Project as far as I can.
>
> I'm fascinated from the language design, and willing to support it (as I'm already in pension).
>
> I think, however, that ooRexx and NetRexx discussions should be splitted,
> having an OWN NetRexx group, which I think should be OPEN.
>
> Also, putting the OPEN source of NetRexx on www.KENAI.com would give NetRexx an instant *visibility* to the Java minded people. As far as I can remember, some 50.000 very knowledgable individuals/companies are a member of www.KENAI.com with various Java related projects.
>
> Far more, as any *own NetRexx* activity can build up quickly....
>
> As far as I got the rules, www.KENAI.com has a very excelennt *standard*
> Project scheme we could simply re-use, thus avoiding all the hassles
> to build everything up again from scratch ...
>
> Comments will be welcome... :-)
>
> Thomas Schneider.
> =============================================================
>
> Am 11.10.2010 00:27, schrieb Chip Davis:
>> On 10/10/10 19:12 [hidden email] said:
>>>
>>> The slides for Virgil Hein's presentation at the May, 2009 RexxLA Symposium
>>> are available on the web.  These slides are (in theory) for RexxLA members
>>> only, but they are readily accessible
>>
>> The RexxLA policy is that Rexx Symposium materials are exclusively available to RexxLA members for one year after the Symposium in which they were presented.  After that time, they are available to everyone.
>>
>>> It appears to me that the quid pro quo is that IBM provides the source to
>>> RexxLA, and RexxLA must provide a plan to administer the open source (and
>>> of course follow through on that plan).
>>
>> And you would be correct.  But that quid pro quo is not negotiable, and as RexxLA is a non-profit organization and René is an unpaid officer, it would be hard to tease out a conflict of interest there. In fact, one could easily argue that his interest, expertise, and current IBM employment are advantages.
>>
>>> The only reasonable conclusion I
>>> can think of is that RexxLA has not yet provided a satisfactory plan or is
>>> unable to commit the resources to administer it.
>>
>> Well, reasonableness tends to be a very subjective measure.  From what I understand (and I am not privy to any more than anyone else, see Virgil's presentation) RexxLA has committed in writing to a plan that meets IBM's objectives, and to providing the resources necessary to execute that plan.  Had that not been the case, our application would not have made it this far.
>>
>>> Based on the OORexx
>>> support, it is obviously a lot of work.
>>
>> True.  We knew that from the outset, but the opportunity was too good to pass up.  Besides, the alternative (letting Object REXX languish in obscurity in an IBM-proprietary vault) was unacceptable to many of us.
>>
>>> Another possibility is that IBM
>>> has actually changed its mind and is trying to renege on the commitment to
>>> open source, but I seriously doubt that is the case.
>>
>> To conclude that IBM has decided to renege on the arrangement would be to assume that something had changed and that they were not telling us of their decision for some reason.  (They don't want to hurt our feelings?)  It's always quicker and easier to say "No".  It's much more difficult and time-consuming to work through all the problems so you can say "Yes".
>>
>> Consider that IBM, like nearly every other company in this economy, is having to do more with less.  I know that most of my IBM contacts are now also doing the work of two or three of their colleagues who are no longer IBM employees.  As has been noted, a pro-bono project such as this cannot have a high priority in such an environment.
>>
>>> It is unfortunate that there was no RexxLA Symposium in 2010 to tell the
>>> world (or at least the members :) what progress was made.  Outsiders can
>>> only speculate on what has and has not been done in the year and a half
>>> since the 2009 Symposium.
>>
>> If by "outsiders" you mean "those who have not signed that NDA", I doubt that there would have been much that could have been legally shared.  As for their speculations, in the absence of knowledge one way or the other, I tend to seek the counsel of Friar Ockham.
>>
>> Yes, it is a shame that we were able to string together only 20 years worth of Rexx Symposiums.  It was also miracle that we did.  Everyone wants to be a guest; only the truly selfless volunteer to host.
>>
>> -Chip-
>>
>>
>> _______________________________________________
>> Ibm-netrexx mailing list
>> [hidden email]
>>
>>
>
>
> --
> Thomas Schneider Projects ReyC & LOGOS on www.KENAI.com
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
>

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Thomas.Schneider.Wien]

Hi Rene,
   could you point me to an URL where I can read about the multi-lingual JVM?
Thomas.
===========================================================
Am 13.10.2010 14:49, schrieb René Jansen:

<base href="x-msg://892/">Mike,

thanks for your interesting post. I would like to point out some things to think about. Your general proposition is that we should not needlessly occupy ourselves with bytecode because it might introduce support issues, and that I can agree with. But I would like to draw your attention to several issues here:

- the interpreter part of NetRexx already 'mucks' with bytecode and classloaders because it needs to

- jruby (at least - I am not that into Jython) needs bytecode manipulation, to the effect that Charles Nutter did write a bytecode assembler integrated into JRuby for this purpose

- the new calls for dynamic invocation 'invokedynamic' and tail recursion in Java 7 mlvm (multi-language virtual machine) do not have Java syntax elements dedicated to them

This last item means that all research into dynamic methods, like ooRexx has, needs to be done in bytecode

The article where the posted link points to is interesting but quite dated; the Java VM world in the Hotspot era is quite different and the compiler and VM optimize a lot more than the article states; this still does not inlfuence your main proposition however. I also think it is wise to leverage higher level compilers; if we choose these meticulously, we might end up with a lot of platforms to run NetRexx on, well into the future.

best regards,

René Jansen.

On 13 okt 2010, at 13:21, Measel, Mike wrote:

George, I know you are talking to MC but let me offer some real world observations on bytecode, and why I think the way nrx works now is just fine.

 

The company I work for started back in ’00 offering a java performance tool that worked by means of bytecode insertion. 

 

At that time we were unique and cozy with big blue services because we could find problems quickly, but whenever our name appeared in a thread dump we were also a target of support.  And our name appeared a lot since we can insert ourselves into each and every method.

 

Along the way, we bounced off of things like AspectJ and again were often accused of being a problem although we usually exposed the developer in the end.  Btw, we work fine with AspectJ and others if they play by the rules (JSR 163).

 

All this to say, STAY AWAY from the bytecodes and conform to the java rules and use the java tools and all will be good.  And go forth and multiply ( n = n * 1) and yeah all that.

 

(jython and jruby both work the way NetRexx does today)

 

Oh, and you can see the cute little byte codes like this:   (  my previous example the Trexx.class)

 

javap -c Trexx > Trexx.bc

more Trexx.bc

Compiled from "Trexx.nrx"

public class Trexx extends java.lang.Object{

static {};

  Code:

   0:         new       #9; //class netrexx/lang/Rexx

   3:         dup

   4:         iconst_1

   5:         invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   8:         putstatic              #11; //Field $01:Lnetrexx/lang/Rexx;

   11:       return

 

public Trexx();

  Code:

   0:         aload_0

   1:         invokespecial     #13; //Method java/lang/Object."<init>":()V

   4:         aload_0

   5:         invokevirtual      #21; //Method dostuff:()V

   8:         return

 

public void dostuff();

  Code:

   0:         new       #9; //class netrexx/lang/Rexx

   3:         dup

   4:         iconst_0

   5:         invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   8:         astore_1

   9:         new       #9; //class netrexx/lang/Rexx

   12:       dup

   13:       sipush   1000

   16:       invokespecial     #16; //Method netrexx/lang/Rexx."<init>":(S)V

   19:       astore_2

   20:       ldc          #3; //String increment rexx

   22:       invokestatic        #19; //Method netrexx/lang/RexxIO.Say:(Ljava/lang/String;)Z

   25:       pop

   26:       aload_1

   27:       aconst_null

   28:       aload_2

   29:       invokevirtual      #18; //Method netrexx/lang/Rexx.OpLt:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Z

   32:       ifeq        44

   35:       aload_0

   36:       aload_1

   37:       invokevirtual      #22; //Method increment:(Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   40:       astore_1

   41:       goto       26

   44:       aload_1

   45:       invokestatic        #20; //Method netrexx/lang/RexxIO.Say:(Lnetrexx/lang/Rexx;)Z

   48:       pop

   49:       ldc          #2; //String increment integer

   51:       invokestatic        #19; //Method netrexx/lang/RexxIO.Say:(Ljava/lang/String;)Z

   54:       pop

   55:       new       #9; //class netrexx/lang/Rexx

   58:       dup

   59:       new       #9; //class netrexx/lang/Rexx

   62:       dup

   63:       iconst_0

   64:       invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   67:       invokevirtual      #26; //Method netrexx/lang/Rexx.toint:()I

   70:       invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   73:       astore_1

   74:       new       #9; //class netrexx/lang/Rexx

   77:       dup

   78:       sipush   1000

   81:       invokespecial     #16; //Method netrexx/lang/Rexx."<init>":(S)V

   84:       astore_2

   85:       aload_1

   86:       aconst_null

   87:       aload_2

   88:       invokevirtual      #18; //Method netrexx/lang/Rexx.OpLt:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Z

   91:       ifeq        103

   94:       aload_0

   95:       aload_1

   96:       invokevirtual      #22; //Method increment:(Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   99:       astore_1

   100:     goto       85

   103:     aload_1

   104:     invokestatic        #20; //Method netrexx/lang/RexxIO.Say:(Lnetrexx/lang/Rexx;)Z

   107:     pop

   108:     ldc          #4; //String increment string

   110:     invokestatic        #19; //Method netrexx/lang/RexxIO.Say:(Ljava/lang/String;)Z

   113:     pop

   114:     new       #9; //class netrexx/lang/Rexx

   117:     dup

   118:     bipush  48

   120:     invokespecial     #14; //Method netrexx/lang/Rexx."<init>":(C)V

   123:     invokestatic        #25; //Method netrexx/lang/Rexx.toString:(Lnetrexx/lang/Rexx;)Ljava/lang/String;

   126:     invokestatic        #24; //Method netrexx/lang/Rexx.toRexx:(Ljava/lang/String;)Lnetrexx/lang/Rexx;

   129:     astore_1

   130:     new       #9; //class netrexx/lang/Rexx

   133:     dup

   134:     sipush   1000

   137:     invokespecial     #16; //Method netrexx/lang/Rexx."<init>":(S)V

   140:     astore_2

   141:     aload_1

   142:     aconst_null

   143:     aload_2

   144:     invokevirtual      #18; //Method netrexx/lang/Rexx.OpLt:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Z

   147:     ifeq        159

   150:     aload_0

   151:     aload_1

   152:     invokevirtual      #22; //Method increment:(Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   155:     astore_1

   156:     goto       141

   159:     aload_1

   160:     invokestatic        #20; //Method netrexx/lang/RexxIO.Say:(Lnetrexx/lang/Rexx;)Z

   163:     pop

   164:     return

 

public int increment(int);

  Code:

   0:         new       #9; //class netrexx/lang/Rexx

   3:         dup

   4:         iload_1

   5:         invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   8:         aconst_null

   9:         getstatic               #11; //Field $01:Lnetrexx/lang/Rexx;

   12:       invokevirtual      #17; //Method netrexx/lang/Rexx.OpAdd:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   15:       invokevirtual      #26; //Method netrexx/lang/Rexx.toint:()I

   18:       ireturn

 

public java.lang.String increment(java.lang.String);

  Code:

   0:         iconst_0

   1:         istore_2

   2:         aload_1

   3:         invokevirtual      #27; //Method java/lang/String.trim:()Ljava/lang/String;

   6:         invokestatic        #23; //Method java/lang/Integer.parseInt:(Ljava/lang/String;)I

   9:         istore_2

   10:       new       #9; //class netrexx/lang/Rexx

   13:       dup

   14:       iload_2

   15:       invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   18:       aconst_null

   19:       getstatic               #11; //Field $01:Lnetrexx/lang/Rexx;

   22:       invokevirtual      #17; //Method netrexx/lang/Rexx.OpAdd:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   25:       invokestatic        #25; //Method netrexx/lang/Rexx.toString:(Lnetrexx/lang/Rexx;)Ljava/lang/String;

   28:       areturn

 

public netrexx.lang.Rexx increment(netrexx.lang.Rexx);

  Code:

   0:         aload_1

   1:         aconst_null

   2:         getstatic               #11; //Field $01:Lnetrexx/lang/Rexx;

   5:         invokevirtual      #17; //Method netrexx/lang/Rexx.OpAdd:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   8:         areturn

 

public static void main(java.lang.String[]);

  Code:

   0:         new       #5; //class Trexx

   3:         invokespecial     #12; //Method "<init>":()V

   6:         return

 

}

 

<whatageek>In the old days we used to disassemble cobol and see which statements produced more instructions.<whatageek>

 

Good article about why programmers should understand bytecode:

 

http://www.ibm.com/developerworks/ibm/library/it-haggar_bytecode/

 

From: [hidden email] [[hidden email]] On Behalf Of George Hovey
Sent: Sunday, October 10, 2010 2:56 PM
To: IBM Netrexx
Subject: Re: On RexxLA and NetRexx (WAS: Re: [Ibm-netrexx] Down the JAVA trail)

 

Mike, this was very helpful.  I have one further issue for your consideration.  My question about javac was prompted by a nebulous idea that has been on my mind; I would like to expound it in the hope that you will either encourage it or put it to rest.

….

 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[measel]

<base href="x-msg://892/">

Rene, I would be in violent agreement if mucking with the byte code got Interpret into NetRexx. 

 

But, many of the schemes being proposed are from those less literate than you and if it ever does get open sourced then I am most concerned about this weeks cheez-whiz getting smeared on my biscuit and the resulting bad taste.   I’ll support the “Mint” version vs “Ubuntu” if that makes sense.

 

I am guilty of never running it in interpreted mode.   Classfile->executeable Jar-> [ insert Emeril BAM! ]

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of René Jansen
Sent: Wednesday, October 13, 2010 7:50 AM
To: IBM Netrexx
Subject: Re: Don't muck with bytecode --> : Re: [Ibm-netrexx] Down the JAVAtrail)

 

Mike,

 

thanks for your interesting post. I would like to point out some things to think about. Your general proposition is that we should not needlessly occupy ourselves with bytecode because it might introduce support issues, and that I can agree with. But I would like to draw your attention to several issues here:

 

- the interpreter part of NetRexx already 'mucks' with bytecode and classloaders because it needs to

- jruby (at least - I am not that into Jython) needs bytecode manipulation, to the effect that Charles Nutter did write a bytecode assembler integrated into JRuby for this purpose

- the new calls for dynamic invocation 'invokedynamic' and tail recursion in Java 7 mlvm (multi-language virtual machine) do not have Java syntax elements dedicated to them

 

This last item means that all research into dynamic methods, like ooRexx has, needs to be done in bytecode

 

The article where the posted link points to is interesting but quite dated; the Java VM world in the Hotspot era is quite different and the compiler and VM optimize a lot more than the article states; this still does not inlfuence your main proposition however. I also think it is wise to leverage higher level compilers; if we choose these meticulously, we might end up with a lot of platforms to run NetRexx on, well into the future.

 

best regards,

 

René Jansen.

 

 

On 13 okt 2010, at 13:21, Measel, Mike wrote:

George, I know you are talking to MC but let me offer some real world observations on bytecode, and why I think the way nrx works now is just fine.

 

The company I work for started back in ’00 offering a java performance tool that worked by means of bytecode insertion. 

 

At that time we were unique and cozy with big blue services because we could find problems quickly, but whenever our name appeared in a thread dump we were also a target of support.  And our name appeared a lot since we can insert ourselves into each and every method.

 

Along the way, we bounced off of things like AspectJ and again were often accused of being a problem although we usually exposed the developer in the end.  Btw, we work fine with AspectJ and others if they play by the rules (JSR 163).

 

All this to say, STAY AWAY from the bytecodes and conform to the java rules and use the java tools and all will be good.  And go forth and multiply ( n = n * 1) and yeah all that.

 

(jython and jruby both work the way NetRexx does today)

 

Oh, and you can see the cute little byte codes like this:   (  my previous example the Trexx.class)

 

javap -c Trexx > Trexx.bc

more Trexx.bc

Compiled from "Trexx.nrx"

public class Trexx extends java.lang.Object{

static {};

  Code:

   0:         new       #9; //class netrexx/lang/Rexx

   3:         dup

   4:         iconst_1

   5:         invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   8:         putstatic              #11; //Field $01:Lnetrexx/lang/Rexx;

   11:       return

 

public Trexx();

  Code:

   0:         aload_0

   1:         invokespecial     #13; //Method java/lang/Object."<init>":()V

   4:         aload_0

   5:         invokevirtual      #21; //Method dostuff:()V

   8:         return

 

public void dostuff();

  Code:

   0:         new       #9; //class netrexx/lang/Rexx

   3:         dup

   4:         iconst_0

   5:         invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   8:         astore_1

   9:         new       #9; //class netrexx/lang/Rexx

   12:       dup

   13:       sipush   1000

   16:       invokespecial     #16; //Method netrexx/lang/Rexx."<init>":(S)V

   19:       astore_2

   20:       ldc          #3; //String increment rexx

   22:       invokestatic        #19; //Method netrexx/lang/RexxIO.Say:(Ljava/lang/String;)Z

   25:       pop

   26:       aload_1

   27:       aconst_null

   28:       aload_2

   29:       invokevirtual      #18; //Method netrexx/lang/Rexx.OpLt:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Z

   32:       ifeq        44

   35:       aload_0

   36:       aload_1

   37:       invokevirtual      #22; //Method increment:(Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   40:       astore_1

   41:       goto       26

   44:       aload_1

   45:       invokestatic        #20; //Method netrexx/lang/RexxIO.Say:(Lnetrexx/lang/Rexx;)Z

   48:       pop

   49:       ldc          #2; //String increment integer

   51:       invokestatic        #19; //Method netrexx/lang/RexxIO.Say:(Ljava/lang/String;)Z

   54:       pop

   55:       new       #9; //class netrexx/lang/Rexx

   58:       dup

   59:       new       #9; //class netrexx/lang/Rexx

   62:       dup

   63:       iconst_0

   64:       invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   67:       invokevirtual      #26; //Method netrexx/lang/Rexx.toint:()I

   70:       invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   73:       astore_1

   74:       new       #9; //class netrexx/lang/Rexx

   77:       dup

   78:       sipush   1000

   81:       invokespecial     #16; //Method netrexx/lang/Rexx."<init>":(S)V

   84:       astore_2

   85:       aload_1

   86:       aconst_null

   87:       aload_2

   88:       invokevirtual      #18; //Method netrexx/lang/Rexx.OpLt:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Z

   91:       ifeq        103

   94:       aload_0

   95:       aload_1

   96:       invokevirtual      #22; //Method increment:(Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   99:       astore_1

   100:     goto       85

   103:     aload_1

   104:     invokestatic        #20; //Method netrexx/lang/RexxIO.Say:(Lnetrexx/lang/Rexx;)Z

   107:     pop

   108:     ldc          #4; //String increment string

   110:     invokestatic        #19; //Method netrexx/lang/RexxIO.Say:(Ljava/lang/String;)Z

   113:     pop

   114:     new       #9; //class netrexx/lang/Rexx

   117:     dup

   118:     bipush  48

   120:     invokespecial     #14; //Method netrexx/lang/Rexx."<init>":(C)V

   123:     invokestatic        #25; //Method netrexx/lang/Rexx.toString:(Lnetrexx/lang/Rexx;)Ljava/lang/String;

   126:     invokestatic        #24; //Method netrexx/lang/Rexx.toRexx:(Ljava/lang/String;)Lnetrexx/lang/Rexx;

   129:     astore_1

   130:     new       #9; //class netrexx/lang/Rexx

   133:     dup

   134:     sipush   1000

   137:     invokespecial     #16; //Method netrexx/lang/Rexx."<init>":(S)V

   140:     astore_2

   141:     aload_1

   142:     aconst_null

   143:     aload_2

   144:     invokevirtual      #18; //Method netrexx/lang/Rexx.OpLt:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Z

   147:     ifeq        159

   150:     aload_0

   151:     aload_1

   152:     invokevirtual      #22; //Method increment:(Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   155:     astore_1

   156:     goto       141

   159:     aload_1

   160:     invokestatic        #20; //Method netrexx/lang/RexxIO.Say:(Lnetrexx/lang/Rexx;)Z

   163:     pop

   164:     return

 

public int increment(int);

  Code:

   0:         new       #9; //class netrexx/lang/Rexx

   3:         dup

   4:         iload_1

   5:         invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   8:         aconst_null

   9:         getstatic               #11; //Field $01:Lnetrexx/lang/Rexx;

   12:       invokevirtual      #17; //Method netrexx/lang/Rexx.OpAdd:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   15:       invokevirtual      #26; //Method netrexx/lang/Rexx.toint:()I

   18:       ireturn

 

public java.lang.String increment(java.lang.String);

  Code:

   0:         iconst_0

   1:         istore_2

   2:         aload_1

   3:         invokevirtual      #27; //Method java/lang/String.trim:()Ljava/lang/String;

   6:         invokestatic        #23; //Method java/lang/Integer.parseInt:(Ljava/lang/String;)I

   9:         istore_2

   10:       new       #9; //class netrexx/lang/Rexx

   13:       dup

   14:       iload_2

   15:       invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   18:       aconst_null

   19:       getstatic               #11; //Field $01:Lnetrexx/lang/Rexx;

   22:       invokevirtual      #17; //Method netrexx/lang/Rexx.OpAdd:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   25:       invokestatic        #25; //Method netrexx/lang/Rexx.toString:(Lnetrexx/lang/Rexx;)Ljava/lang/String;

   28:       areturn

 

public netrexx.lang.Rexx increment(netrexx.lang.Rexx);

  Code:

   0:         aload_1

   1:         aconst_null

   2:         getstatic               #11; //Field $01:Lnetrexx/lang/Rexx;

   5:         invokevirtual      #17; //Method netrexx/lang/Rexx.OpAdd:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   8:         areturn

 

public static void main(java.lang.String[]);

  Code:

   0:         new       #5; //class Trexx

   3:         invokespecial     #12; //Method "<init>":()V

   6:         return

 

}

 

<whatageek>In the old days we used to disassemble cobol and see which statements produced more instructions.<whatageek>

 

Good article about why programmers should understand bytecode:

 

http://www.ibm.com/developerworks/ibm/library/it-haggar_bytecode/

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of George Hovey
Sent: Sunday, October 10, 2010 2:56 PM
To: IBM Netrexx
Subject: Re: On RexxLA and NetRexx (WAS: Re: [Ibm-netrexx] Down the JAVA trail)

 

Mike, this was very helpful.  I have one further issue for your consideration.  My question about javac was prompted by a nebulous idea that has been on my mind; I would like to expound it in the hope that you will either encourage it or put it to rest.

….

 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Thomas.Schneider.Wien]

  Hi Rene,
    so good to hear from you....

Let me repeat the reason (*my reason*) *why* we should use www.KENAI.com
*and not* SourceForge for the open source release of Netrexx:

1.) SourceForge holds any kinds of projects.
2.) www.KENAI.com holds  *only Java related* projects.
3.) When putting NetRexx to www.KENAI.com, we can easily *exploit* both
it's language recognition to a very broad user base....

As you probably know, Kermit Kiser has already developped a method to
run NetRexx Programs on an ANDROID smart phone.... I got and tested
it -- without any problems -- on my RED BULL HUAWEI Handy !

This would mean, that we can use NetRexx as a language to program
ANDROID handys....

Thinks about the portential market:

Google sells some 60.000 (sixty thousand) ANDROID licences

    *by day*

By day!!!   :-)

... and, if I am reading everything correct, the Goosle CHROME OS is
coming out soon, which will be again Java based, as far as I do know.

Now, think about a language which is able to cater the whole span from a
smart phone to IBM zOS (whithout any re-compilation necessary)

Maybe that's the future of Netrexx we should think about!

Human oriented for human beeings...

Thomas.
==============================================================




Am 13.10.2010 15:05, schrieb René Jansen:

> Tom,
>
> for your information, ooRexx also has discussion groups that are open to everyone that registers, at SourceForge.
>
> best regards,
>
> René.
>
> On 13 okt 2010, at 14:54, Thomas Schneider wrote:
>
>> Hello Chip,
>>    thanks for the insights....
>>
>> I am offering, again, to help in the NetRexx Project as far as I can.
>>
>> I'm fascinated from the language design, and willing to support it (as I'm already in pension).
>>
>> I think, however, that ooRexx and NetRexx discussions should be splitted,
>> having an OWN NetRexx group, which I think should be OPEN.
>>
>> Also, putting the OPEN source of NetRexx on www.KENAI.com would give NetRexx an instant *visibility* to the Java minded people. As far as I can remember, some 50.000 very knowledgable individuals/companies are a member of www.KENAI.com with various Java related projects.
>>
>> Far more, as any *own NetRexx* activity can build up quickly....
>>
>> As far as I got the rules, www.KENAI.com has a very excelennt *standard*
>> Project scheme we could simply re-use, thus avoiding all the hassles
>> to build everything up again from scratch ...
>>
>> Comments will be welcome... :-)
>>
>> Thomas Schneider.
>> =============================================================
>>
>> Am 11.10.2010 00:27, schrieb Chip Davis:
>>> On 10/10/10 19:12 [hidden email] said:
>>>> The slides for Virgil Hein's presentation at the May, 2009 RexxLA Symposium
>>>> are available on the web.  These slides are (in theory) for RexxLA members
>>>> only, but they are readily accessible
>>> The RexxLA policy is that Rexx Symposium materials are exclusively available to RexxLA members for one year after the Symposium in which they were presented.  After that time, they are available to everyone.
>>>
>>>> It appears to me that the quid pro quo is that IBM provides the source to
>>>> RexxLA, and RexxLA must provide a plan to administer the open source (and
>>>> of course follow through on that plan).
>>> And you would be correct.  But that quid pro quo is not negotiable, and as RexxLA is a non-profit organization and René is an unpaid officer, it would be hard to tease out a conflict of interest there. In fact, one could easily argue that his interest, expertise, and current IBM employment are advantages.
>>>
>>>> The only reasonable conclusion I
>>>> can think of is that RexxLA has not yet provided a satisfactory plan or is
>>>> unable to commit the resources to administer it.
>>> Well, reasonableness tends to be a very subjective measure.  From what I understand (and I am not privy to any more than anyone else, see Virgil's presentation) RexxLA has committed in writing to a plan that meets IBM's objectives, and to providing the resources necessary to execute that plan.  Had that not been the case, our application would not have made it this far.
>>>
>>>> Based on the OORexx
>>>> support, it is obviously a lot of work.
>>> True.  We knew that from the outset, but the opportunity was too good to pass up.  Besides, the alternative (letting Object REXX languish in obscurity in an IBM-proprietary vault) was unacceptable to many of us.
>>>
>>>> Another possibility is that IBM
>>>> has actually changed its mind and is trying to renege on the commitment to
>>>> open source, but I seriously doubt that is the case.
>>> To conclude that IBM has decided to renege on the arrangement would be to assume that something had changed and that they were not telling us of their decision for some reason.  (They don't want to hurt our feelings?)  It's always quicker and easier to say "No".  It's much more difficult and time-consuming to work through all the problems so you can say "Yes".
>>>
>>> Consider that IBM, like nearly every other company in this economy, is having to do more with less.  I know that most of my IBM contacts are now also doing the work of two or three of their colleagues who are no longer IBM employees.  As has been noted, a pro-bono project such as this cannot have a high priority in such an environment.
>>>
>>>> It is unfortunate that there was no RexxLA Symposium in 2010 to tell the
>>>> world (or at least the members :) what progress was made.  Outsiders can
>>>> only speculate on what has and has not been done in the year and a half
>>>> since the 2009 Symposium.
>>> If by "outsiders" you mean "those who have not signed that NDA", I doubt that there would have been much that could have been legally shared.  As for their speculations, in the absence of knowledge one way or the other, I tend to seek the counsel of Friar Ockham.
>>>
>>> Yes, it is a shame that we were able to string together only 20 years worth of Rexx Symposiums.  It was also miracle that we did.  Everyone wants to be a guest; only the truly selfless volunteer to host.
>>>
>>> -Chip-
>>>
>>>
>>> _______________________________________________
>>> Ibm-netrexx mailing list
>>> [hidden email]
>>>
>>>
>>
>> --
>> Thomas Schneider Projects ReyC&  LOGOS on www.KENAI.com
>> _______________________________________________
>> Ibm-netrexx mailing list
>> [hidden email]
>>
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
>
>

--
Thomas Schneider Projects ReyC & LOGOS on www.KENAI.com
_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Robert L Hamilton]

Somewhere in this thread was the statement

"<whatageek>In the old days we used to disassemble cobol and see which statements produced more instructions.<whatageek>"

I don't understand; the COBOL compiler generates machine code which is linked into the load-lib by the linkage editor OR has something changed??? The Bell Labs C compiler also used machine code to boot-strap the compiler.

bobh

On Wed, Oct 13, 2010 at 6:21 AM, Measel, Mike <[hidden email]> wrote:

George, I know you are talking to MC but let me offer some real world observations on bytecode, and why I think the way nrx works now is just fine.

 

The company I work for started back in ’00 offering a java performance tool that worked by means of bytecode insertion. 

 

At that time we were unique and cozy with big blue services because we could find problems quickly, but whenever our name appeared in a thread dump we were also a target of support.  And our name appeared a lot since we can insert ourselves into each and every method.

 

Along the way, we bounced off of things like AspectJ and again were often accused of being a problem although we usually exposed the developer in the end.  Btw, we work fine with AspectJ and others if they play by the rules (JSR 163).

 

All this to say, STAY AWAY from the bytecodes and conform to the java rules and use the java tools and all will be good.  And go forth and multiply ( n = n * 1) and yeah all that.

 

(jython and jruby both work the way NetRexx does today)

 

Oh, and you can see the cute little byte codes like this:   (  my previous example the Trexx.class)

 

javap -c Trexx > Trexx.bc

more Trexx.bc

Compiled from "Trexx.nrx"

public class Trexx extends java.lang.Object{

static {};

  Code:

   0:         new       #9; //class netrexx/lang/Rexx

   3:         dup

   4:         iconst_1

   5:         invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   8:         putstatic              #11; //Field $01:Lnetrexx/lang/Rexx;

   11:       return

 

public Trexx();

  Code:

   0:         aload_0

   1:         invokespecial     #13; //Method java/lang/Object."<init>":()V

   4:         aload_0

   5:         invokevirtual      #21; //Method dostuff:()V

   8:         return

 

public void dostuff();

  Code:

   0:         new       #9; //class netrexx/lang/Rexx

   3:         dup

   4:         iconst_0

   5:         invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   8:         astore_1

   9:         new       #9; //class netrexx/lang/Rexx

   12:       dup

   13:       sipush   1000

   16:       invokespecial     #16; //Method netrexx/lang/Rexx."<init>":(S)V

   19:       astore_2

   20:       ldc          #3; //String increment rexx

   22:       invokestatic        #19; //Method netrexx/lang/RexxIO.Say:(Ljava/lang/String;)Z

   25:       pop

   26:       aload_1

   27:       aconst_null

   28:       aload_2

   29:       invokevirtual      #18; //Method netrexx/lang/Rexx.OpLt:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Z

   32:       ifeq        44

   35:       aload_0

   36:       aload_1

   37:       invokevirtual      #22; //Method increment:(Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   40:       astore_1

   41:       goto       26

   44:       aload_1

   45:       invokestatic        #20; //Method netrexx/lang/RexxIO.Say:(Lnetrexx/lang/Rexx;)Z

   48:       pop

   49:       ldc          #2; //String increment integer

   51:       invokestatic        #19; //Method netrexx/lang/RexxIO.Say:(Ljava/lang/String;)Z

   54:       pop

   55:       new       #9; //class netrexx/lang/Rexx

   58:       dup

   59:       new       #9; //class netrexx/lang/Rexx

   62:       dup

   63:       iconst_0

   64:       invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   67:       invokevirtual      #26; //Method netrexx/lang/Rexx.toint:()I

   70:       invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   73:       astore_1

   74:       new       #9; //class netrexx/lang/Rexx

   77:       dup

   78:       sipush   1000

   81:       invokespecial     #16; //Method netrexx/lang/Rexx."<init>":(S)V

   84:       astore_2

   85:       aload_1

   86:       aconst_null

   87:       aload_2

   88:       invokevirtual      #18; //Method netrexx/lang/Rexx.OpLt:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Z

   91:       ifeq        103

   94:       aload_0

   95:       aload_1

   96:       invokevirtual      #22; //Method increment:(Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   99:       astore_1

   100:     goto       85

   103:     aload_1

   104:     invokestatic        #20; //Method netrexx/lang/RexxIO.Say:(Lnetrexx/lang/Rexx;)Z

   107:     pop

   108:     ldc          #4; //String increment string

   110:     invokestatic        #19; //Method netrexx/lang/RexxIO.Say:(Ljava/lang/String;)Z

   113:     pop

   114:     new       #9; //class netrexx/lang/Rexx

   117:     dup

   118:     bipush  48

   120:     invokespecial     #14; //Method netrexx/lang/Rexx."<init>":(C)V

   123:     invokestatic        #25; //Method netrexx/lang/Rexx.toString:(Lnetrexx/lang/Rexx;)Ljava/lang/String;

   126:     invokestatic        #24; //Method netrexx/lang/Rexx.toRexx:(Ljava/lang/String;)Lnetrexx/lang/Rexx;

   129:     astore_1

   130:     new       #9; //class netrexx/lang/Rexx

   133:     dup

   134:     sipush   1000

   137:     invokespecial     #16; //Method netrexx/lang/Rexx."<init>":(S)V

   140:     astore_2

   141:     aload_1

   142:     aconst_null

   143:     aload_2

   144:     invokevirtual      #18; //Method netrexx/lang/Rexx.OpLt:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Z

   147:     ifeq        159

   150:     aload_0

   151:     aload_1

   152:     invokevirtual      #22; //Method increment:(Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   155:     astore_1

   156:     goto       141

   159:     aload_1

   160:     invokestatic        #20; //Method netrexx/lang/RexxIO.Say:(Lnetrexx/lang/Rexx;)Z

   163:     pop

   164:     return

 

public int increment(int);

  Code:

   0:         new       #9; //class netrexx/lang/Rexx

   3:         dup

   4:         iload_1

   5:         invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   8:         aconst_null

   9:         getstatic               #11; //Field $01:Lnetrexx/lang/Rexx;

   12:       invokevirtual      #17; //Method netrexx/lang/Rexx.OpAdd:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   15:       invokevirtual      #26; //Method netrexx/lang/Rexx.toint:()I

   18:       ireturn

 

public java.lang.String increment(java.lang.String);

  Code:

   0:         iconst_0

   1:         istore_2

   2:         aload_1

   3:         invokevirtual      #27; //Method java/lang/String.trim:()Ljava/lang/String;

   6:         invokestatic        #23; //Method java/lang/Integer.parseInt:(Ljava/lang/String;)I

   9:         istore_2

   10:       new       #9; //class netrexx/lang/Rexx

   13:       dup

   14:       iload_2

   15:       invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   18:       aconst_null

   19:       getstatic               #11; //Field $01:Lnetrexx/lang/Rexx;

   22:       invokevirtual      #17; //Method netrexx/lang/Rexx.OpAdd:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   25:       invokestatic        #25; //Method netrexx/lang/Rexx.toString:(Lnetrexx/lang/Rexx;)Ljava/lang/String;

   28:       areturn

 

public netrexx.lang.Rexx increment(netrexx.lang.Rexx);

  Code:

   0:         aload_1

   1:         aconst_null

   2:         getstatic               #11; //Field $01:Lnetrexx/lang/Rexx;

   5:         invokevirtual      #17; //Method netrexx/lang/Rexx.OpAdd:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   8:         areturn

 

public static void main(java.lang.String[]);

  Code:

   0:         new       #5; //class Trexx

   3:         invokespecial     #12; //Method "<init>":()V

   6:         return

 

}

 

<whatageek>In the old days we used to disassemble cobol and see which statements produced more instructions.<whatageek>

 

Good article about why programmers should understand bytecode:

 

http://www.ibm.com/developerworks/ibm/library/it-haggar_bytecode/

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of George Hovey
Sent: Sunday, October 10, 2010 2:56 PM
To: IBM Netrexx
Subject: Re: On RexxLA and NetRexx (WAS: Re: [Ibm-netrexx] Down the JAVA trail)

 

Mike, this was very helpful.  I have one further issue for your consideration.  My question about javac was prompted by a nebulous idea that has been on my mind; I would like to expound it in the hope that you will either encourage it or put it to rest.

….

 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Thomas.Schneider.Wien]

Hello Rene, Mike Measel, and all:

As you know -- from various advertisements -- I'm working on ReyC (the Rey Compiler) and PP (The Program Porting machine).

Both of them have a different approach than the current Netrexx Compiler.

The do produce an

* internal DECL of the code-fragment, which might be even a COBOL/PLI/ IBM Rexx Compiler COPY book (COBOL) or INCLUDE File (PLI or iBM Rexx Compiler)
* internal CODE (which may reference the DECL's)

Both are documented, by the way...

This 'artificial' internal Code is something like *unifying* the various IF statements, etc, thus transcripting the original source of all the supported languages *to the same internal decl and code.

ReyC already successfully SCANS any program (ooRexx included), and I am
in the final stages to PARSE and TRANSFORM the code : from *function oriented* (as COBOL, PL/I, and classic COMPILED Rexx) to NetRexx, as the primary target language.

For NetRexx, I did (experimentally) introduce some new VERBS but this is another story.

In contrast to Rexx2Nrx, the ReyC source code is all written in NetRexx (Rexx2Nrx has been originally developped in CMS IBm Compilted Rexx, with a LOT of %included files).

When interested in the progress, please join project ReyC on www.KENAI.com

When not interested, ignore this message.

Thomas Schneider.
==============================================================

emnt
Am 13.10.2010 15:25, schrieb Measel, Mike:

<base href="x-msg://892/">

Rene, I would be in violent agreement if mucking with the byte code got Interpret into NetRexx. 

 

But, many of the schemes being proposed are from those less literate than you and if it ever does get open sourced then I am most concerned about this weeks cheez-whiz getting smeared on my biscuit and the resulting bad taste.   I’ll support the “Mint” version vs “Ubuntu” if that makes sense.

 

I am guilty of never running it in interpreted mode.   Classfile->executeable Jar-> [ insert Emeril BAM! ]

 

From: [hidden email] [[hidden email]] On Behalf Of René Jansen
Sent: Wednesday, October 13, 2010 7:50 AM
To: IBM Netrexx
Subject: Re: Don't muck with bytecode --> : Re: [Ibm-netrexx] Down the JAVAtrail)

 

Mike,

 

thanks for your interesting post. I would like to point out some things to think about. Your general proposition is that we should not needlessly occupy ourselves with bytecode because it might introduce support issues, and that I can agree with. But I would like to draw your attention to several issues here:

 

- the interpreter part of NetRexx already 'mucks' with bytecode and classloaders because it needs to

- jruby (at least - I am not that into Jython) needs bytecode manipulation, to the effect that Charles Nutter did write a bytecode assembler integrated into JRuby for this purpose

- the new calls for dynamic invocation 'invokedynamic' and tail recursion in Java 7 mlvm (multi-language virtual machine) do not have Java syntax elements dedicated to them

 

This last item means that all research into dynamic methods, like ooRexx has, needs to be done in bytecode

 

The article where the posted link points to is interesting but quite dated; the Java VM world in the Hotspot era is quite different and the compiler and VM optimize a lot more than the article states; this still does not inlfuence your main proposition however. I also think it is wise to leverage higher level compilers; if we choose these meticulously, we might end up with a lot of platforms to run NetRexx on, well into the future.

 

best regards,

 

René Jansen.

 

 

On 13 okt 2010, at 13:21, Measel, Mike wrote:

George, I know you are talking to MC but let me offer some real world observations on bytecode, and why I think the way nrx works now is just fine.

 

The company I work for started back in ’00 offering a java performance tool that worked by means of bytecode insertion. 

 

At that time we were unique and cozy with big blue services because we could find problems quickly, but whenever our name appeared in a thread dump we were also a target of support.  And our name appeared a lot since we can insert ourselves into each and every method.

 

Along the way, we bounced off of things like AspectJ and again were often accused of being a problem although we usually exposed the developer in the end.  Btw, we work fine with AspectJ and others if they play by the rules (JSR 163).

 

All this to say, STAY AWAY from the bytecodes and conform to the java rules and use the java tools and all will be good.  And go forth and multiply ( n = n * 1) and yeah all that.

 

(jython and jruby both work the way NetRexx does today)

 

Oh, and you can see the cute little byte codes like this:   (  my previous example the Trexx.class)

 

javap -c Trexx > Trexx.bc

more Trexx.bc

Compiled from "Trexx.nrx"

public class Trexx extends java.lang.Object{

static {};

  Code:

   0:         new       #9; //class netrexx/lang/Rexx

   3:         dup

   4:         iconst_1

   5:         invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   8:         putstatic              #11; //Field $01:Lnetrexx/lang/Rexx;

   11:       return

 

public Trexx();

  Code:

   0:         aload_0

   1:         invokespecial     #13; //Method java/lang/Object."<init>":()V

   4:         aload_0

   5:         invokevirtual      #21; //Method dostuff:()V

   8:         return

 

public void dostuff();

  Code:

   0:         new       #9; //class netrexx/lang/Rexx

   3:         dup

   4:         iconst_0

   5:         invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   8:         astore_1

   9:         new       #9; //class netrexx/lang/Rexx

   12:       dup

   13:       sipush   1000

   16:       invokespecial     #16; //Method netrexx/lang/Rexx."<init>":(S)V

   19:       astore_2

   20:       ldc          #3; //String increment rexx

   22:       invokestatic        #19; //Method netrexx/lang/RexxIO.Say:(Ljava/lang/String;)Z

   25:       pop

   26:       aload_1

   27:       aconst_null

   28:       aload_2

   29:       invokevirtual      #18; //Method netrexx/lang/Rexx.OpLt:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Z

   32:       ifeq        44

   35:       aload_0

   36:       aload_1

   37:       invokevirtual      #22; //Method increment:(Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   40:       astore_1

   41:       goto       26

   44:       aload_1

   45:       invokestatic        #20; //Method netrexx/lang/RexxIO.Say:(Lnetrexx/lang/Rexx;)Z

   48:       pop

   49:       ldc          #2; //String increment integer

   51:       invokestatic        #19; //Method netrexx/lang/RexxIO.Say:(Ljava/lang/String;)Z

   54:       pop

   55:       new       #9; //class netrexx/lang/Rexx

   58:       dup

   59:       new       #9; //class netrexx/lang/Rexx

   62:       dup

   63:       iconst_0

   64:       invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   67:       invokevirtual      #26; //Method netrexx/lang/Rexx.toint:()I

   70:       invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   73:       astore_1

   74:       new       #9; //class netrexx/lang/Rexx

   77:       dup

   78:       sipush   1000

   81:       invokespecial     #16; //Method netrexx/lang/Rexx."<init>":(S)V

   84:       astore_2

   85:       aload_1

   86:       aconst_null

   87:       aload_2

   88:       invokevirtual      #18; //Method netrexx/lang/Rexx.OpLt:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Z

   91:       ifeq        103

   94:       aload_0

   95:       aload_1

   96:       invokevirtual      #22; //Method increment:(Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   99:       astore_1

   100:     goto       85

   103:     aload_1

   104:     invokestatic        #20; //Method netrexx/lang/RexxIO.Say:(Lnetrexx/lang/Rexx;)Z

   107:     pop

   108:     ldc          #4; //String increment string

   110:     invokestatic        #19; //Method netrexx/lang/RexxIO.Say:(Ljava/lang/String;)Z

   113:     pop

   114:     new       #9; //class netrexx/lang/Rexx

   117:     dup

   118:     bipush  48

   120:     invokespecial     #14; //Method netrexx/lang/Rexx."<init>":(C)V

   123:     invokestatic        #25; //Method netrexx/lang/Rexx.toString:(Lnetrexx/lang/Rexx;)Ljava/lang/String;

   126:     invokestatic        #24; //Method netrexx/lang/Rexx.toRexx:(Ljava/lang/String;)Lnetrexx/lang/Rexx;

   129:     astore_1

   130:     new       #9; //class netrexx/lang/Rexx

   133:     dup

   134:     sipush   1000

   137:     invokespecial     #16; //Method netrexx/lang/Rexx."<init>":(S)V

   140:     astore_2

   141:     aload_1

   142:     aconst_null

   143:     aload_2

   144:     invokevirtual      #18; //Method netrexx/lang/Rexx.OpLt:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Z

   147:     ifeq        159

   150:     aload_0

   151:     aload_1

   152:     invokevirtual      #22; //Method increment:(Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   155:     astore_1

   156:     goto       141

   159:     aload_1

   160:     invokestatic        #20; //Method netrexx/lang/RexxIO.Say:(Lnetrexx/lang/Rexx;)Z

   163:     pop

   164:     return

 

public int increment(int);

  Code:

   0:         new       #9; //class netrexx/lang/Rexx

   3:         dup

   4:         iload_1

   5:         invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   8:         aconst_null

   9:         getstatic               #11; //Field $01:Lnetrexx/lang/Rexx;

   12:       invokevirtual      #17; //Method netrexx/lang/Rexx.OpAdd:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   15:       invokevirtual      #26; //Method netrexx/lang/Rexx.toint:()I

   18:       ireturn

 

public java.lang.String increment(java.lang.String);

  Code:

   0:         iconst_0

   1:         istore_2

   2:         aload_1

   3:         invokevirtual      #27; //Method java/lang/String.trim:()Ljava/lang/String;

   6:         invokestatic        #23; //Method java/lang/Integer.parseInt:(Ljava/lang/String;)I

   9:         istore_2

   10:       new       #9; //class netrexx/lang/Rexx

   13:       dup

   14:       iload_2

   15:       invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   18:       aconst_null

   19:       getstatic               #11; //Field $01:Lnetrexx/lang/Rexx;

   22:       invokevirtual      #17; //Method netrexx/lang/Rexx.OpAdd:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   25:       invokestatic        #25; //Method netrexx/lang/Rexx.toString:(Lnetrexx/lang/Rexx;)Ljava/lang/String;

   28:       areturn

 

public netrexx.lang.Rexx increment(netrexx.lang.Rexx);

  Code:

   0:         aload_1

   1:         aconst_null

   2:         getstatic               #11; //Field $01:Lnetrexx/lang/Rexx;

   5:         invokevirtual      #17; //Method netrexx/lang/Rexx.OpAdd:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   8:         areturn

 

public static void main(java.lang.String[]);

  Code:

   0:         new       #5; //class Trexx

   3:         invokespecial     #12; //Method "<init>":()V

   6:         return

 

}

 

<whatageek>In the old days we used to disassemble cobol and see which statements produced more instructions.<whatageek>

 

Good article about why programmers should understand bytecode:

 

http://www.ibm.com/developerworks/ibm/library/it-haggar_bytecode/

 

From: [hidden email] [[hidden email]] On Behalf Of George Hovey
Sent: Sunday, October 10, 2010 2:56 PM
To: IBM Netrexx
Subject: Re: On RexxLA and NetRexx (WAS: Re: [Ibm-netrexx] Down the JAVA trail)

 

Mike, this was very helpful.  I have one further issue for your consideration.  My question about javac was prompted by a nebulous idea that has been on my mind; I would like to expound it in the hope that you will either encourage it or put it to rest.

….

 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Thomas.Schneider.Wien]

Hello Robert,
   there are a LOT of COBOL Compilers on the market.

Some of them even generate intermediate C-Code (as COBOL-IT does) and are open source...

My attempt is to compile and/or TRANSFORM COBOL to NetRexx ...

See the spec of ReyC and PP (The Program Porting machine) on
my new home-page www.thsitc.com

Thomas.
=============================================================
Am 13.10.2010 15:46, schrieb Robert Hamilton:

Somewhere in this thread was the statement

"<whatageek>In the old days we used to disassemble cobol and see which statements produced more instructions.<whatageek>"

I don't understand; the COBOL compiler generates machine code which is linked into the load-lib by the linkage editor OR has something changed??? The Bell Labs C compiler also used machine code to boot-strap the compiler.

bobh

On Wed, Oct 13, 2010 at 6:21 AM, Measel, Mike <[hidden email]> wrote:

George, I know you are talking to MC but let me offer some real world observations on bytecode, and why I think the way nrx works now is just fine.

 

The company I work for started back in ’00 offering a java performance tool that worked by means of bytecode insertion. 

 

At that time we were unique and cozy with big blue services because we could find problems quickly, but whenever our name appeared in a thread dump we were also a target of support.  And our name appeared a lot since we can insert ourselves into each and every method.

 

Along the way, we bounced off of things like AspectJ and again were often accused of being a problem although we usually exposed the developer in the end.  Btw, we work fine with AspectJ and others if they play by the rules (JSR 163).

 

All this to say, STAY AWAY from the bytecodes and conform to the java rules and use the java tools and all will be good.  And go forth and multiply ( n = n * 1) and yeah all that.

 

(jython and jruby both work the way NetRexx does today)

 

Oh, and you can see the cute little byte codes like this:   (  my previous example the Trexx.class)

 

javap -c Trexx > Trexx.bc

more Trexx.bc

Compiled from "Trexx.nrx"

public class Trexx extends java.lang.Object{

static {};

  Code:

   0:         new       #9; //class netrexx/lang/Rexx

   3:         dup

   4:         iconst_1

   5:         invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   8:         putstatic              #11; //Field $01:Lnetrexx/lang/Rexx;

   11:       return

 

public Trexx();

  Code:

   0:         aload_0

   1:         invokespecial     #13; //Method java/lang/Object."<init>":()V

   4:         aload_0

   5:         invokevirtual      #21; //Method dostuff:()V

   8:         return

 

public void dostuff();

  Code:

   0:         new       #9; //class netrexx/lang/Rexx

   3:         dup

   4:         iconst_0

   5:         invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   8:         astore_1

   9:         new       #9; //class netrexx/lang/Rexx

   12:       dup

   13:       sipush   1000

   16:       invokespecial     #16; //Method netrexx/lang/Rexx."<init>":(S)V

   19:       astore_2

   20:       ldc          #3; //String increment rexx

   22:       invokestatic        #19; //Method netrexx/lang/RexxIO.Say:(Ljava/lang/String;)Z

   25:       pop

   26:       aload_1

   27:       aconst_null

   28:       aload_2

   29:       invokevirtual      #18; //Method netrexx/lang/Rexx.OpLt:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Z

   32:       ifeq        44

   35:       aload_0

   36:       aload_1

   37:       invokevirtual      #22; //Method increment:(Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   40:       astore_1

   41:       goto       26

   44:       aload_1

   45:       invokestatic        #20; //Method netrexx/lang/RexxIO.Say:(Lnetrexx/lang/Rexx;)Z

   48:       pop

   49:       ldc          #2; //String increment integer

   51:       invokestatic        #19; //Method netrexx/lang/RexxIO.Say:(Ljava/lang/String;)Z

   54:       pop

   55:       new       #9; //class netrexx/lang/Rexx

   58:       dup

   59:       new       #9; //class netrexx/lang/Rexx

   62:       dup

   63:       iconst_0

   64:       invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   67:       invokevirtual      #26; //Method netrexx/lang/Rexx.toint:()I

   70:       invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   73:       astore_1

   74:       new       #9; //class netrexx/lang/Rexx

   77:       dup

   78:       sipush   1000

   81:       invokespecial     #16; //Method netrexx/lang/Rexx."<init>":(S)V

   84:       astore_2

   85:       aload_1

   86:       aconst_null

   87:       aload_2

   88:       invokevirtual      #18; //Method netrexx/lang/Rexx.OpLt:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Z

   91:       ifeq        103

   94:       aload_0

   95:       aload_1

   96:       invokevirtual      #22; //Method increment:(Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   99:       astore_1

   100:     goto       85

   103:     aload_1

   104:     invokestatic        #20; //Method netrexx/lang/RexxIO.Say:(Lnetrexx/lang/Rexx;)Z

   107:     pop

   108:     ldc          #4; //String increment string

   110:     invokestatic        #19; //Method netrexx/lang/RexxIO.Say:(Ljava/lang/String;)Z

   113:     pop

   114:     new       #9; //class netrexx/lang/Rexx

   117:     dup

   118:     bipush  48

   120:     invokespecial     #14; //Method netrexx/lang/Rexx."<init>":(C)V

   123:     invokestatic        #25; //Method netrexx/lang/Rexx.toString:(Lnetrexx/lang/Rexx;)Ljava/lang/String;

   126:     invokestatic        #24; //Method netrexx/lang/Rexx.toRexx:(Ljava/lang/String;)Lnetrexx/lang/Rexx;

   129:     astore_1

   130:     new       #9; //class netrexx/lang/Rexx

   133:     dup

   134:     sipush   1000

   137:     invokespecial     #16; //Method netrexx/lang/Rexx."<init>":(S)V

   140:     astore_2

   141:     aload_1

   142:     aconst_null

   143:     aload_2

   144:     invokevirtual      #18; //Method netrexx/lang/Rexx.OpLt:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Z

   147:     ifeq        159

   150:     aload_0

   151:     aload_1

   152:     invokevirtual      #22; //Method increment:(Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   155:     astore_1

   156:     goto       141

   159:     aload_1

   160:     invokestatic        #20; //Method netrexx/lang/RexxIO.Say:(Lnetrexx/lang/Rexx;)Z

   163:     pop

   164:     return

 

public int increment(int);

  Code:

   0:         new       #9; //class netrexx/lang/Rexx

   3:         dup

   4:         iload_1

   5:         invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   8:         aconst_null

   9:         getstatic               #11; //Field $01:Lnetrexx/lang/Rexx;

   12:       invokevirtual      #17; //Method netrexx/lang/Rexx.OpAdd:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   15:       invokevirtual      #26; //Method netrexx/lang/Rexx.toint:()I

   18:       ireturn

 

public java.lang.String increment(java.lang.String);

  Code:

   0:         iconst_0

   1:         istore_2

   2:         aload_1

   3:         invokevirtual      #27; //Method java/lang/String.trim:()Ljava/lang/String;

   6:         invokestatic        #23; //Method java/lang/Integer.parseInt:(Ljava/lang/String;)I

   9:         istore_2

   10:       new       #9; //class netrexx/lang/Rexx

   13:       dup

   14:       iload_2

   15:       invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   18:       aconst_null

   19:       getstatic               #11; //Field $01:Lnetrexx/lang/Rexx;

   22:       invokevirtual      #17; //Method netrexx/lang/Rexx.OpAdd:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   25:       invokestatic        #25; //Method netrexx/lang/Rexx.toString:(Lnetrexx/lang/Rexx;)Ljava/lang/String;

   28:       areturn

 

public netrexx.lang.Rexx increment(netrexx.lang.Rexx);

  Code:

   0:         aload_1

   1:         aconst_null

   2:         getstatic               #11; //Field $01:Lnetrexx/lang/Rexx;

   5:         invokevirtual      #17; //Method netrexx/lang/Rexx.OpAdd:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   8:         areturn

 

public static void main(java.lang.String[]);

  Code:

   0:         new       #5; //class Trexx

   3:         invokespecial     #12; //Method "<init>":()V

   6:         return

 

}

 

<whatageek>In the old days we used to disassemble cobol and see which statements produced more instructions.<whatageek>

 

Good article about why programmers should understand bytecode:

 

http://www.ibm.com/developerworks/ibm/library/it-haggar_bytecode/

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of George Hovey
Sent: Sunday, October 10, 2010 2:56 PM
To: IBM Netrexx
Subject: Re: On RexxLA and NetRexx (WAS: Re: [Ibm-netrexx] Down the JAVA trail)

 

Mike, this was very helpful.  I have one further issue for your consideration.  My question about javac was prompted by a nebulous idea that has been on my mind; I would like to expound it in the hope that you will either encourage it or put it to rest.

….

 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[measel]

Oops, wrong term Bob.  What I meant to say was we would actually take various statements and compile them and review the machine code output and it’s been so long that I don’t remember the option but maybe you do.  In my musing I was thinking that it would be good to review all of the suggested changes to NetRexx as to the bytecode generated.

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Robert Hamilton
Sent: Wednesday, October 13, 2010 8:47 AM
To: IBM Netrexx
Subject: Re: Don't muck with bytecode --> : Re: [Ibm-netrexx] Down the JAVAtrail)

 

Somewhere in this thread was the statement

"<whatageek>In the old days we used to disassemble cobol and see which statements produced more instructions.<whatageek>"

I don't understand; the COBOL compiler generates machine code which is linked into the load-lib by the linkage editor OR has something changed??? The Bell Labs C compiler also used machine code to boot-strap the compiler.

bobh

On Wed, Oct 13, 2010 at 6:21 AM, Measel, Mike <[hidden email]> wrote:

George, I know you are talking to MC but let me offer some real world observations on bytecode, and why I think the way nrx works now is just fine.

 

The company I work for started back in ’00 offering a java performance tool that worked by means of bytecode insertion. 

 

At that time we were unique and cozy with big blue services because we could find problems quickly, but whenever our name appeared in a thread dump we were also a target of support.  And our name appeared a lot since we can insert ourselves into each and every method.

 

Along the way, we bounced off of things like AspectJ and again were often accused of being a problem although we usually exposed the developer in the end.  Btw, we work fine with AspectJ and others if they play by the rules (JSR 163).

 

All this to say, STAY AWAY from the bytecodes and conform to the java rules and use the java tools and all will be good.  And go forth and multiply ( n = n * 1) and yeah all that.

 

(jython and jruby both work the way NetRexx does today)

 

Oh, and you can see the cute little byte codes like this:   (  my previous example the Trexx.class)

 

javap -c Trexx > Trexx.bc

more Trexx.bc

Compiled from "Trexx.nrx"

public class Trexx extends java.lang.Object{

static {};

  Code:

   0:         new       #9; //class netrexx/lang/Rexx

   3:         dup

   4:         iconst_1

   5:         invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   8:         putstatic              #11; //Field $01:Lnetrexx/lang/Rexx;

   11:       return

 

public Trexx();

  Code:

   0:         aload_0

   1:         invokespecial     #13; //Method java/lang/Object."<init>":()V

   4:         aload_0

   5:         invokevirtual      #21; //Method dostuff:()V

   8:         return

 

public void dostuff();

  Code:

   0:         new       #9; //class netrexx/lang/Rexx

   3:         dup

   4:         iconst_0

   5:         invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   8:         astore_1

   9:         new       #9; //class netrexx/lang/Rexx

   12:       dup

   13:       sipush   1000

   16:       invokespecial     #16; //Method netrexx/lang/Rexx."<init>":(S)V

   19:       astore_2

   20:       ldc          #3; //String increment rexx

   22:       invokestatic        #19; //Method netrexx/lang/RexxIO.Say:(Ljava/lang/String;)Z

   25:       pop

   26:       aload_1

   27:       aconst_null

   28:       aload_2

   29:       invokevirtual      #18; //Method netrexx/lang/Rexx.OpLt:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Z

   32:       ifeq        44

   35:       aload_0

   36:       aload_1

   37:       invokevirtual      #22; //Method increment:(Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   40:       astore_1

   41:       goto       26

   44:       aload_1

   45:       invokestatic        #20; //Method netrexx/lang/RexxIO.Say:(Lnetrexx/lang/Rexx;)Z

   48:       pop

   49:       ldc          #2; //String increment integer

   51:       invokestatic        #19; //Method netrexx/lang/RexxIO.Say:(Ljava/lang/String;)Z

   54:       pop

   55:       new       #9; //class netrexx/lang/Rexx

   58:       dup

   59:       new       #9; //class netrexx/lang/Rexx

   62:       dup

   63:       iconst_0

   64:       invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   67:       invokevirtual      #26; //Method netrexx/lang/Rexx.toint:()I

   70:       invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   73:       astore_1

   74:       new       #9; //class netrexx/lang/Rexx

   77:       dup

   78:       sipush   1000

   81:       invokespecial     #16; //Method netrexx/lang/Rexx."<init>":(S)V

   84:       astore_2

   85:       aload_1

   86:       aconst_null

   87:       aload_2

   88:       invokevirtual      #18; //Method netrexx/lang/Rexx.OpLt:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Z

   91:       ifeq        103

   94:       aload_0

   95:       aload_1

   96:       invokevirtual      #22; //Method increment:(Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   99:       astore_1

   100:     goto       85

   103:     aload_1

   104:     invokestatic        #20; //Method netrexx/lang/RexxIO.Say:(Lnetrexx/lang/Rexx;)Z

   107:     pop

   108:     ldc          #4; //String increment string

   110:     invokestatic        #19; //Method netrexx/lang/RexxIO.Say:(Ljava/lang/String;)Z

   113:     pop

   114:     new       #9; //class netrexx/lang/Rexx

   117:     dup

   118:     bipush  48

   120:     invokespecial     #14; //Method netrexx/lang/Rexx."<init>":(C)V

   123:     invokestatic        #25; //Method netrexx/lang/Rexx.toString:(Lnetrexx/lang/Rexx;)Ljava/lang/String;

   126:     invokestatic        #24; //Method netrexx/lang/Rexx.toRexx:(Ljava/lang/String;)Lnetrexx/lang/Rexx;

   129:     astore_1

   130:     new       #9; //class netrexx/lang/Rexx

   133:     dup

   134:     sipush   1000

   137:     invokespecial     #16; //Method netrexx/lang/Rexx."<init>":(S)V

   140:     astore_2

   141:     aload_1

   142:     aconst_null

   143:     aload_2

   144:     invokevirtual      #18; //Method netrexx/lang/Rexx.OpLt:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Z

   147:     ifeq        159

   150:     aload_0

   151:     aload_1

   152:     invokevirtual      #22; //Method increment:(Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   155:     astore_1

   156:     goto       141

   159:     aload_1

   160:     invokestatic        #20; //Method netrexx/lang/RexxIO.Say:(Lnetrexx/lang/Rexx;)Z

   163:     pop

   164:     return

 

public int increment(int);

  Code:

   0:         new       #9; //class netrexx/lang/Rexx

   3:         dup

   4:         iload_1

   5:         invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   8:         aconst_null

   9:         getstatic               #11; //Field $01:Lnetrexx/lang/Rexx;

   12:       invokevirtual      #17; //Method netrexx/lang/Rexx.OpAdd:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   15:       invokevirtual      #26; //Method netrexx/lang/Rexx.toint:()I

   18:       ireturn

 

public java.lang.String increment(java.lang.String);

  Code:

   0:         iconst_0

   1:         istore_2

   2:         aload_1

   3:         invokevirtual      #27; //Method java/lang/String.trim:()Ljava/lang/String;

   6:         invokestatic        #23; //Method java/lang/Integer.parseInt:(Ljava/lang/String;)I

   9:         istore_2

   10:       new       #9; //class netrexx/lang/Rexx

   13:       dup

   14:       iload_2

   15:       invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   18:       aconst_null

   19:       getstatic               #11; //Field $01:Lnetrexx/lang/Rexx;

   22:       invokevirtual      #17; //Method netrexx/lang/Rexx.OpAdd:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   25:       invokestatic        #25; //Method netrexx/lang/Rexx.toString:(Lnetrexx/lang/Rexx;)Ljava/lang/String;

   28:       areturn

 

public netrexx.lang.Rexx increment(netrexx.lang.Rexx);

  Code:

   0:         aload_1

   1:         aconst_null

   2:         getstatic               #11; //Field $01:Lnetrexx/lang/Rexx;

   5:         invokevirtual      #17; //Method netrexx/lang/Rexx.OpAdd:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   8:         areturn

 

public static void main(java.lang.String[]);

  Code:

   0:         new       #5; //class Trexx

   3:         invokespecial     #12; //Method "<init>":()V

   6:         return

 

}

 

<whatageek>In the old days we used to disassemble cobol and see which statements produced more instructions.<whatageek>

 

Good article about why programmers should understand bytecode:

 

http://www.ibm.com/developerworks/ibm/library/it-haggar_bytecode/

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of George Hovey
Sent: Sunday, October 10, 2010 2:56 PM
To: IBM Netrexx
Subject: Re: On RexxLA and NetRexx (WAS: Re: [Ibm-netrexx] Down the JAVA trail)

 

Mike, this was very helpful.  I have one further issue for your consideration.  My question about javac was prompted by a nebulous idea that has been on my mind; I would like to expound it in the hope that you will either encourage it or put it to rest.

….

 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Mike Cowlishaw]

George wrote: 
 

 Mike, this was very helpful.  I have one further issue for your consideration.  My question about javac was prompted by a nebulous idea that has been on my mind; I would like to expound it in the hope that you will either encourage it or put it to rest.

Some may have noticed that I harp on maintaining Java interoperability (though its existence right now seems to be in some doubt).  This is partly because I feel that NetRexx has a natural constituency in programmers currently writing in Java (I assume that we all want NetRexx to spread and thrive in any and all directions).  I am not saying that Java programmers are in any way to be preferred to others who might be attracted  -- NetRexx should be a "big tent" -- just that they are "low hanging fruit".  Further, non-Java programmers are not second class citizens in NetRexx.  A vast category of programs can be written without ever (knowingly) invoking a Java class, and this will only improve if more Rexx features can be incorporated.  And even those wishing to exploit the Java Class Library don't need to know the Java language per se, but just conventions used in describing and invoking the library.

I made the switch to Java technology at a small software development firm which tried Java at the instigation of a talented, thoughtful and experienced programmer (not me).  He did this by prototyping a system for a bid at a speed management had never seen.  This won the bid and permission to form a group to fulfill the contract using Java.  I jumped at the chance to join and was quickly won over (as was the company, which presently stipulated that all future development would be done in Java) by the speed and relative painlessness of java development.

At about the same time I encountered NetRexx.  I noticed it because of positive experiences with Rexx under OS/2 (I especially liked the Rexx-extensible editor).  I vowed that if I ever returned to my preferred mode of employment, sole software cook and bottle washer for a scientific research group, NetRexx would be my development language.  This eventually came to pass.

I never even mentioned NetRexx to my employers as it was clearly a nonstarter from their standpoint.  But I also had a blind spot: I thought of it as an either/or choice --  you either developed in NetRexx or in Java.  But why not have mixed Java and NetRexx as an option?  Then forward looking programmers in organizations using Java could go to their managers and say "I've found a language that improves the Java development process.  It is totally interoperable with Java, but significantly simplifies coding.  It has some powerful intrinsic features not present in Java, and as a bonus, reduces carpal tunnel syndrome.  Furthermore you don't need to bet the farm on it.  It can be introduced in small doses to the current code base while we gain confidence in it."  In my dreams, time passes and one day a programmers asks "why not make NetRexx our standard language?  We still have full access to our company library, it will reduce development costs and ..."  Later, many more would email their bosses "I've been reading about this NetRexx phenomenon and here's some UTube links.  I know these people sound like fanatics but ..."

Hence my original question about javac.  I am not a computer scientist or language maven, but it seems to be, to a degree I only dimly understand, a guarantor of java compatibility.  But to attract Java developers, we have to offer some kind of contract analogous in strength and clarity to "100% pure Java".  I suppose we would also have to "keep up" with Java on certain source features in order to avoid deteriorating relations with Java programmers.  This could be problematical considering that we have no control over Java's direction.

Sorry for the long winded preamble.  The bottom line -- I'd appreciate a candid assessment of these ideas.
 

Hard to answer all that simply -- but yes I always thought as NetRexx having a place in a mixed Java/NetRexx environment.   That was one major reason for NetRexxC having the ability to emit formatted and commented Java code.  This meant that for managers who insisted that using NetRexx was too risky ('what if the language stops being developed") could be answered with "well at any time you can save the .java files and throw away the NetRexx and revert to being a 'pure Java' shop").

 

This also came in useful when I was working with Sun .. I could write decimal arithmetic algorithms in NetRexx and then ship the code in Java to the Sun engineers who didn't know NetRexx.   Similarly the decimal class in the ICU4J package was required to be in Java -- but was written in NetRexx.   (See http://speleotrove.com/decimal/decimalj/decimalj.html)

 

Mike

 

 

 

 

 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Thomas.Schneider.Wien]

Hi Mike, & all,
 
   I would like to publish the *PP Code* for the public.

It *is* already there in the SVN David Requena thanksfully built up for my
ReyC project ....

BUT: It has to be reviewed, reviewed, ... *and* reviewed again.

Hence, what shall I do:

Publish it on www.kenai.com,

*or* on www.thsitc.com

Comments will be welcome... :-)
Thomas.
======================================================
Am 13.10.2010 16:39, schrieb Measel, Mike:

Oops, wrong term Bob.  What I meant to say was we would actually take various statements and compile them and review the machine code output and it’s been so long that I don’t remember the option but maybe you do.  In my musing I was thinking that it would be good to review all of the suggested changes to NetRexx as to the bytecode generated.

 

From: [hidden email] [[hidden email]] On Behalf Of Robert Hamilton
Sent: Wednesday, October 13, 2010 8:47 AM
To: IBM Netrexx
Subject: Re: Don't muck with bytecode --> : Re: [Ibm-netrexx] Down the JAVAtrail)

 

Somewhere in this thread was the statement

"<whatageek>In the old days we used to disassemble cobol and see which statements produced more instructions.<whatageek>"

I don't understand; the COBOL compiler generates machine code which is linked into the load-lib by the linkage editor OR has something changed??? The Bell Labs C compiler also used machine code to boot-strap the compiler.

bobh

On Wed, Oct 13, 2010 at 6:21 AM, Measel, Mike <[hidden email]> wrote:

George, I know you are talking to MC but let me offer some real world observations on bytecode, and why I think the way nrx works now is just fine.

 

The company I work for started back in ’00 offering a java performance tool that worked by means of bytecode insertion. 

 

At that time we were unique and cozy with big blue services because we could find problems quickly, but whenever our name appeared in a thread dump we were also a target of support.  And our name appeared a lot since we can insert ourselves into each and every method.

 

Along the way, we bounced off of things like AspectJ and again were often accused of being a problem although we usually exposed the developer in the end.  Btw, we work fine with AspectJ and others if they play by the rules (JSR 163).

 

All this to say, STAY AWAY from the bytecodes and conform to the java rules and use the java tools and all will be good.  And go forth and multiply ( n = n * 1) and yeah all that.

 

(jython and jruby both work the way NetRexx does today)

 

Oh, and you can see the cute little byte codes like this:   (  my previous example the Trexx.class)

 

javap -c Trexx > Trexx.bc

more Trexx.bc

Compiled from "Trexx.nrx"

public class Trexx extends java.lang.Object{

static {};

  Code:

   0:         new       #9; //class netrexx/lang/Rexx

   3:         dup

   4:         iconst_1

   5:         invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   8:         putstatic              #11; //Field $01:Lnetrexx/lang/Rexx;

   11:       return

 

public Trexx();

  Code:

   0:         aload_0

   1:         invokespecial     #13; //Method java/lang/Object."<init>":()V

   4:         aload_0

   5:         invokevirtual      #21; //Method dostuff:()V

   8:         return

 

public void dostuff();

  Code:

   0:         new       #9; //class netrexx/lang/Rexx

   3:         dup

   4:         iconst_0

   5:         invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   8:         astore_1

   9:         new       #9; //class netrexx/lang/Rexx

   12:       dup

   13:       sipush   1000

   16:       invokespecial     #16; //Method netrexx/lang/Rexx."<init>":(S)V

   19:       astore_2

   20:       ldc          #3; //String increment rexx

   22:       invokestatic        #19; //Method netrexx/lang/RexxIO.Say:(Ljava/lang/String;)Z

   25:       pop

   26:       aload_1

   27:       aconst_null

   28:       aload_2

   29:       invokevirtual      #18; //Method netrexx/lang/Rexx.OpLt:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Z

   32:       ifeq        44

   35:       aload_0

   36:       aload_1

   37:       invokevirtual      #22; //Method increment:(Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   40:       astore_1

   41:       goto       26

   44:       aload_1

   45:       invokestatic        #20; //Method netrexx/lang/RexxIO.Say:(Lnetrexx/lang/Rexx;)Z

   48:       pop

   49:       ldc          #2; //String increment integer

   51:       invokestatic        #19; //Method netrexx/lang/RexxIO.Say:(Ljava/lang/String;)Z

   54:       pop

   55:       new       #9; //class netrexx/lang/Rexx

   58:       dup

   59:       new       #9; //class netrexx/lang/Rexx

   62:       dup

   63:       iconst_0

   64:       invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   67:       invokevirtual      #26; //Method netrexx/lang/Rexx.toint:()I

   70:       invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   73:       astore_1

   74:       new       #9; //class netrexx/lang/Rexx

   77:       dup

   78:       sipush   1000

   81:       invokespecial     #16; //Method netrexx/lang/Rexx."<init>":(S)V

   84:       astore_2

   85:       aload_1

   86:       aconst_null

   87:       aload_2

   88:       invokevirtual      #18; //Method netrexx/lang/Rexx.OpLt:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Z

   91:       ifeq        103

   94:       aload_0

   95:       aload_1

   96:       invokevirtual      #22; //Method increment:(Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   99:       astore_1

   100:     goto       85

   103:     aload_1

   104:     invokestatic        #20; //Method netrexx/lang/RexxIO.Say:(Lnetrexx/lang/Rexx;)Z

   107:     pop

   108:     ldc          #4; //String increment string

   110:     invokestatic        #19; //Method netrexx/lang/RexxIO.Say:(Ljava/lang/String;)Z

   113:     pop

   114:     new       #9; //class netrexx/lang/Rexx

   117:     dup

   118:     bipush  48

   120:     invokespecial     #14; //Method netrexx/lang/Rexx."<init>":(C)V

   123:     invokestatic        #25; //Method netrexx/lang/Rexx.toString:(Lnetrexx/lang/Rexx;)Ljava/lang/String;

   126:     invokestatic        #24; //Method netrexx/lang/Rexx.toRexx:(Ljava/lang/String;)Lnetrexx/lang/Rexx;

   129:     astore_1

   130:     new       #9; //class netrexx/lang/Rexx

   133:     dup

   134:     sipush   1000

   137:     invokespecial     #16; //Method netrexx/lang/Rexx."<init>":(S)V

   140:     astore_2

   141:     aload_1

   142:     aconst_null

   143:     aload_2

   144:     invokevirtual      #18; //Method netrexx/lang/Rexx.OpLt:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Z

   147:     ifeq        159

   150:     aload_0

   151:     aload_1

   152:     invokevirtual      #22; //Method increment:(Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   155:     astore_1

   156:     goto       141

   159:     aload_1

   160:     invokestatic        #20; //Method netrexx/lang/RexxIO.Say:(Lnetrexx/lang/Rexx;)Z

   163:     pop

   164:     return

 

public int increment(int);

  Code:

   0:         new       #9; //class netrexx/lang/Rexx

   3:         dup

   4:         iload_1

   5:         invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   8:         aconst_null

   9:         getstatic               #11; //Field $01:Lnetrexx/lang/Rexx;

   12:       invokevirtual      #17; //Method netrexx/lang/Rexx.OpAdd:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   15:       invokevirtual      #26; //Method netrexx/lang/Rexx.toint:()I

   18:       ireturn

 

public java.lang.String increment(java.lang.String);

  Code:

   0:         iconst_0

   1:         istore_2

   2:         aload_1

   3:         invokevirtual      #27; //Method java/lang/String.trim:()Ljava/lang/String;

   6:         invokestatic        #23; //Method java/lang/Integer.parseInt:(Ljava/lang/String;)I

   9:         istore_2

   10:       new       #9; //class netrexx/lang/Rexx

   13:       dup

   14:       iload_2

   15:       invokespecial     #15; //Method netrexx/lang/Rexx."<init>":(I)V

   18:       aconst_null

   19:       getstatic               #11; //Field $01:Lnetrexx/lang/Rexx;

   22:       invokevirtual      #17; //Method netrexx/lang/Rexx.OpAdd:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   25:       invokestatic        #25; //Method netrexx/lang/Rexx.toString:(Lnetrexx/lang/Rexx;)Ljava/lang/String;

   28:       areturn

 

public netrexx.lang.Rexx increment(netrexx.lang.Rexx);

  Code:

   0:         aload_1

   1:         aconst_null

   2:         getstatic               #11; //Field $01:Lnetrexx/lang/Rexx;

   5:         invokevirtual      #17; //Method netrexx/lang/Rexx.OpAdd:(Lnetrexx/lang/RexxSet;Lnetrexx/lang/Rexx;)Lnetrexx/lang/Rexx;

   8:         areturn

 

public static void main(java.lang.String[]);

  Code:

   0:         new       #5; //class Trexx

   3:         invokespecial     #12; //Method "<init>":()V

   6:         return

 

}

 

<whatageek>In the old days we used to disassemble cobol and see which statements produced more instructions.<whatageek>

 

Good article about why programmers should understand bytecode:

 

http://www.ibm.com/developerworks/ibm/library/it-haggar_bytecode/

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of George Hovey
Sent: Sunday, October 10, 2010 2:56 PM
To: IBM Netrexx
Subject: Re: On RexxLA and NetRexx (WAS: Re: [Ibm-netrexx] Down the JAVA trail)

 

Mike, this was very helpful.  I have one further issue for your consideration.  My question about javac was prompted by a nebulous idea that has been on my mind; I would like to expound it in the hope that you will either encourage it or put it to rest.

….

 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]