RE: Prototyping a constructor of java String class

Otto,

I don't think there should be any performance concern when using literals as 
they
are probably constructed based upon the provided attributes.  The bigger 
impact, I
suspect, is in using predefined work fields to account for the fields maximum
length.  This impact is probably offset if you define the field with 
options(*varsize).
As you may have already determined, specifying options(*varsize) on the java
prototype doesn't have any negative affect (at least on the surface) on the 
results
of the string constructor.  I used the the following code snippet to test the
various options.

<snippet>
     H THREAD(*SERIALIZE) BndDir('QC2LE') DFTACTGRP(*NO) ACTGRP(*NEW)
     Dprintf           PR                  EXTPROC('printf')
     D                                 *   value options(*string)
     Dnewstring        PR              O   EXTPROC(*JAVA:
     D                                     'java.lang.String':
     D                                     *CONSTRUCTOR)
     D                                     CLASS(*JAVA:'java.lang.String')
     D*******                     65535A   CONST varying
     D*******                     65535A   CONST
     D                            65535A   varying CONST options(*varsize)
     DGetStringChar    PR         65535a   varying
     D                                     EXTPROC(*JAVA:'java.lang.String':
     D                                     'getBytes')
     DGetStringLng     PR            10I 0 EXTPROC(*JAVA:'java.lang.String':
     D                                     'length')
     DString           S               O   CLASS(*JAVA:'java.lang.String')
     D iostring        C                   CONST('11111111112222222222333333333-
     D                                     3AAAAAAAAAABBBBBBBBBBCCCCCCCCCC')
     DInputString      S          65535A   varying
     Dstring_long      S             10I 0
      *
     C*****              EVAL      String = newString ('123456789')
     C                   EVAL      String = newString (iostring)
     C                   EVAL      String_long = GetStringLng(String)
     C                   callp     Printf('String length is ' +
     C                             %char(string_long) + x'15')
      * Extract & display input string.
     C                   eval      inputString = GetStringChar(String)
     C                   callp     Printf(inputString + x'15')
     C*********          dump(a)
     C                   move      '1'           *inlr
<snippet>      

As you pointed out, not providing "VARYING" on the prototype forces the creation
of a 65k java string padded with blanks.  Conversely, specifying VARYING on the
prototype returns a non-padded string with the length of the string input.  From
a performance persepctive, this clearly appears to be the best approach as, 
again,
I suspect the compiler is invoking the NewString JNI function.  I'm hoping 
Barbara
can provide more in-depth insight as to what's happening at the lower levels.

>From a performance perspective, the bigger penalty may be in retrieving java 
>strings
in RPG via the "getBytes" method call.  While you can specify VARYING on the
prototype, I'm not sure if (in my example) 65k is allocated for the returned
string.  This would provide a serious performance issue if calling "getBytes"
multiple times.  Again, this depends on what is happening at the lower levels.

Going back to your original post, I (in my humble opinion) don't think how the
temporary literals are created is a significant issue because, at least in my
experience, the majority of the time, fields are passed, not literals.  That
said, specifying both "varying" and "options(*varsize)" on the prototype appears
to address both scenarios (pending any comments from Barbara).

In researching your question though, I am a little curious (concerned?) about
the performance affects when retrieving java strings in RPG.  Hmmm... ;-)

Respectfully,

Michael Rooney
Citigroup International