org.vishia.java2C.test
Class TestString

java.lang.Object
  org.vishia.java2C.test.TestString

public class TestString
extends java.lang.Object

This class contains some examples to test String functionality.

Situation for String preparation in C: A String preparation in C in embedded applications is often necessary in situations of error reporting or output of states. The typically choice is usage of sprintf(buffer, "text-format", arguments, ...). This approach have some risks which may produce errors in runtime:

• The type of arguments should be matched to the designation of parts in text-format. An error of detail is possible, the user should programmed carefully. The compiler doesn't detect errors.
• If the size of buffer is less, an overflow isn't detect. An overflow may occur, if a value is unexpected, and the numbering formating produce a less longer output. char*-Arguments are critically too, because there length may be rate faulty because that is depending of outer code.
• If a char* is used as argument, and the pointer is faulty, an unexpected buffer overflow may be produced in the sprintf.
• The buffer should be provided by the users environment. If the buffer is defined in Stack, and the String is produced and used temporary, it's okay. But a software correction in calling routines, which doesn't uses to pointer to the buffer for copy, instead save the pointer, are not detected at compile time.

• Simple concatenations of Strings just like String result = "value=" + value. This variant needs a buffer, which is allocated in the heap and managed by garbage collection.
• Usage of a StringBuffer or StringBuilder. The adequate code is result.setLength(0); result.append("value=").append(value); The StringBuffer-Object can be allocated as an element of any class, the memory space is allocated in the instance including the buffer itself, hence no dynamic memory allocation is necessary.
• Java knows a adequate to sprintf approach using String.format(formatString, arguments ...). This method is some more safety as the C-sprintf, because a buffer overflow is detected and the types of arguments are well known. But the method works with dynamic memory only.

buffer1

java.lang.StringBuilder buffer1

A reference to another struct.

bufferInit

final java.lang.StringBuffer bufferInit

A reference to another struct, but without need of garbage collection. @java2c=noGC.

bufferEmbedded

final java.lang.StringBuilder bufferEmbedded

empty

static final java.lang.String empty

See Also:

Constant Field Values

stringRef

java.lang.String stringRef

A reference to a String in memory. The String may be a reference to a constant String or to the content inside a StringBuffer. see usages.

sbufferFix

private final java.lang.StringBuffer sbufferFix

Creates an embedded instance as StringBuffer with immediate space for the chars.

strArray

private final java.lang.String[] strArray

strArray2

private java.lang.String[] strArray2

charArray

private char[] charArray

oStream1

java.io.FileOutputStream oStream1

oStream2

java.io.FileOutputStream oStream2

TestString

TestString(java.lang.StringBuffer bufferInit)

processString

static int processString(java.lang.String str)

Help method which processes a String.

testStringConcatenationInStack

void testStringConcatenationInStack(int value,
                                    float fValue)

Examples for String concatenations.

This method tests and shows a concatenation of String without using dynamic memory. it uses Stack instances only, because all Strings are used temporary. This patterns are able to use in a system without any dynamically memory, at example for String preparing in an interrupt routine of embedded control.

See comments on the code line of java source-code in comparision with the produced C-code in xxx

testStringConcatenationWithTemps

void testStringConcatenationWithTemps(int value,
                                      float fValue)

Examples for String concatenations.

This method tests and shows a concatenation of String using garbage collection.

First example: concatenation and assignment: The Java-code is:

    String ss = "test " + value + " miles";
    System.out.println(ss);
    this.stringRef = ss;
 

A String will be built stack-locally with concatenation. Than this String will be used first as parameter for a method, than it is saved in the instance (persistent). In C it is translated to:

    StringJc ss;
      ...
    StringBufferJc *_tempString1_1=null; //J2C: temporary Stringbuffer for String concatenation
      ...
    ss = 
      ( _tempString1_1 = new_StringBufferJc(-1, _thCxt)
      , setTemporary_StringBufferJc(_tempString1_1)
      , append_z_StringBufferJc(_tempString1_1, "test ", _thCxt)
      , append_I_StringBufferJc(_tempString1_1, value, _thCxt)
      , append_z_StringBufferJc(_tempString1_1, " miles", _thCxt)
      , toString_StringBufferJc(_tempString1_1)
      );
    println_s_PrintStreamJc(REFJc(out_SystemJc), ss, _thCxt);
    set_StringJc(&(ythis->stringRef), ss);
      ....
    activateGarbageCollectorAccess_BlockHeapJc(&_tempString1_1->base.object);
 

The following principles are used:

• Adequate to the implementation in Java the concatenation uses a StringBuffer internally for the concatenation expression. The StringBuffer is allocated in heap calling new_StringBufferJc(...).
• There is a possibility of working without allocated memory for such embedded software systems, which should not use any dynamic memory and garbage collection: The new StringBuffer can be a thread-local existing buffer. In this case only one concatenation of Strings is able to use per Thread. The content of the produced String should be copied in the next instruction. That is a restriction of programming, but it allows to work without garbage collection. Commonly a garbage collector and dynamic memory should be able to use. The CRuntimeJavalike-Library provides a solution using blocks with equal size (BlockHeap).
• The StringBuffer is dedicated as temporary. The reference to the StringBuffer isn't known in the users programming. Therefore the user can't work with it. Only the result String ss uses the buffer.
• All concatenations are implemented using append...(...)-methods.
• The last operation with the StringBuffer is the call of toString(...) to get the String. A String instance contains only the pointer to the text itself (char* in Buffer), the number of chars and a few special bits. That are at maximum 2 Registers with 32 bit, compendious in a struct StringJc and defined operation-system-depend in a struct OS_ValuePtr to support optimal memory and register usage for the target platform.
• The String is stored and taken as parameter as value, never as a reference (not as StringJc*). The method println(...) got the String as value.
• To store a String in class variables (persistent), the method setref_StringJc(...) is used. This method sets the backward reference to the memory block of the block-heap, which contains the pointer to the text and sets the index of backward reference in the reference in class (ythis->stringRef) With this operation the block is referenced now.
• The temporary StringBufferJc is designated to managed by Garbage collection at least, before finish the routine. Because the String is referenced in this example, the garbage collector will test the reference. Elsewhere the block will be freed from garbage collector. That is typically if a String is prepared and used only locally.

testStringConcatenationUsingBuilder

void testStringConcatenationUsingBuilder(int value)

testStringParameter

java.lang.String testStringParameter(java.lang.String s1,
                                     java.lang.String s2)

testStringParameter

void testStringParameter()

testFormat

private java.lang.String testFormat(int value,
                                    float fValue)

Parameters:

value -

fValue -

Returns:

testReplace

private void testReplace()

testInsertCharArray

private void testInsertCharArray()

toString

public java.lang.String toString()

Overrides:

toString in class java.lang.Object

testGarbageString

void testGarbageString()

testStringBuffer

void testStringBuffer()

Example for StringBuffer usage.

The StringBuffer bufferEmbedded is created as an embedded part of this class structure. It has a fix length, the text is part of the instance, using immediate buffer. The usage of such an buffer for string preparing is a proper decision if no dynamic memory should be used, and the user has the controlling and responsibility about the String instances.
The Java-code to prepare a string is:

    bufferEmbedded.setLength(0);
    bufferEmbedded.append("content:").append(stringRef);
    System.out.println(bufferEmbedded);
    String s1 = bufferEmbedded.toString();
    System.out.println(s1);
    this.stringRef = s1;
 

In this example the buffer is cleared, than a content is appended. The Result is used to print out with given StringBuffer. Than the buffer-content is stored in a String calling the toString(...)-method. That result is used to print out too. At last the String is stored in a class variable.

The resulting C-code is:

    StringJc s1;
    ...
    setLength_StringBufferJc(& (ythis->bufferEmbedded.sb), 0, _thCxt);
      ( append_s_StringBufferJc(& (ythis->bufferEmbedded.sb), s0_StringJc("content:"), _thCxt)
      , append_s_StringBufferJc(& (ythis->bufferEmbedded.sb), ythis->stringRef, _thCxt)
      );
    println_sb_PrintStreamJc(REFJc(out_SystemJc), & (ythis->bufferEmbedded.sb), _thCxt);
    s1 = toString_StringBufferJc(& (ythis->bufferEmbedded.sb));
    println_s_PrintStreamJc(REFJc(out_SystemJc), s1, _thCxt);
    set_StringJc(&(ythis->stringRef), s1);
 

The C-code follows the Java-code. The concatenation of append is resolved like described in TestAllConcepts.checkConcatenationSimple().

testNonPersistenceOfStrings

void testNonPersistenceOfStrings()

Persistence of Strings The method toString(...) needs to turn one's attentions: Generally, a String is constant. Because the buffer content of a StringBuffer may be changed after calling toString(...), the text have to be copied to an independent buffer. The Java implementation do so. But this is an additional effort regarding typically applications in the fast real-time embedded world. Mostly the StringBuffer isn't change immediately, rather the got String is processed and thereby copied in the current thread like shown in the example testStringBuffer().

Thats why some methods toString...(...) in the CRuntimeJavalike-Library have two modes:

• Compatible-mode with Java, but with more effort: toString...(...) creates an extra buffer for the returned String in heap.
• Small-effort-mode: toString_StringBufferJc references the String in the StringBuffer-instance, no extra buffer is used. toString...(...) from other classes uses the thread-local Buffer, it can be used only one for one toString-result in thread, the result is to copy outside. This mode saves calculation time and prevent an extra memory allocation. In this case the String is dedicated with a bit mNonPersists__StringJc.

Both modes are able to choice. The default is the compatible mode with Java. A method which uses the small-effort mode can be designated with a @ java2c=optimize-toString annotation in its description block. Than the small-effort-mode is valid for that method body.

The prevention of copy a String in a allocated buffer is not only a question of calculation time effort. If a routine in a fast interrupt uses a lightweight String preparation but an allocated buffer is necessary, that module needs resources, which are inadequately for it. Therefore the optimize mode is recommended. The Java-source should written in a form, which doesn't change a StringBuffer from which a derived temporary String is still in use. First do all with the String, than change the Buffer. Than the optimized C-code works correctly.

If the String is saved persistent in a class variable, it must copy to an own buffer. In this case an alteration of the StringBuffer content is able to expect while the persistent String is ready to use. It would be a non-obvious programming situation if the persistent String is referenced the buffer evermore. Thats why the assignment using set_StringJc(...) checks whether the String is non persistent. If it is so, a new StringBuffer is allocated in heap and the String is copied into. That StringBuffer is only referenced by this String, and therefore it is fix and managed by garbage collection.

An adequate problem are given by the toString(...) implementations of some other Objects. Because mostly the Strings will be processed immediately, at example as input for an concatenation, extra buffers should be saved to minimize effort. For preparing the returned String a thread-local StringBuffer is able to use. That is thread-save, but only one instance of that buffer exists per thread. This buffer have never to be referenced. Thats why the same dedication is used: mNonPersists__StringJc. The user can produce a faulty code, a code which runs in Java because Java is save but it doesn't run in C after translation. This is the disadvantage of this concept, the concession to the optimizing of calculation time and preventing additional dynamically memory management. The user may write minimal other statements to get a safety code.

This routine is designated with the @ java2c=optimize-toString., but the code is faulty for that:

    bufferEmbedded.setLength(0);
    String ss = bufferEmbedded.append("content:").append(234).toString();
    bufferEmbedded.setLength(0);
    bufferEmbedded.append(" TEST ").append(ss);
    ss = bufferEmbedded.toString();
    System.out.println(ss);
 

The buffer content is saved in ss, but after them the buffer is changed. The translated C-code is:

  bool _bOptimizeStringSave;  //J2C: annotation optimize-toString
    ...
  _bOptimizeStringSave = optimizeString_ThCxt(_thCxt, true);
  { 
    StringJc ss;
    setLength_StringBufferJc(& (ythis->bufferEmbedded.sb), 0, _thCxt);
    ss = 
      ( append_s_StringBufferJc(& (ythis->bufferEmbedded.sb), s0_StringJc("content:"), _thCxt)
      , append_i_StringBufferJc(& (ythis->bufferEmbedded.sb), 234, _thCxt)
      , toString_StringBufferJc(& (ythis->bufferEmbedded.sb), _thCxt)
      );
    setLength_StringBufferJc(& (ythis->bufferEmbedded.sb), 0, _thCxt);

      ( append_s_StringBufferJc(& (ythis->bufferEmbedded.sb), s0_StringJc(" TEST "), _thCxt)
      , append_s_StringBufferJc(& (ythis->bufferEmbedded.sb), ss, _thCxt)
      );
    ss = toString_StringBufferJc(& (ythis->bufferEmbedded.sb), _thCxt);
    println_s_PrintStreamJc(REFJc(out_SystemJc), ss, _thCxt);
  }
  optimizeString_ThCxt(_thCxt, _bOptimizeStringSave);
 

The optimizing is set in the Thread-context-data. After the routine the saved state of optimizing is recovered.

testPersistenceOfStrings

void testPersistenceOfStrings()

This routine has the same content like testNonPersistenceOfStrings(), but the persistence is set per default, no @ java2c=optimize-toString. is written here. The result is correct. Debug it in C!

testDateString

java.lang.String testDateString(java.lang.String sPath,
                                int ident)

This routine uses the class java.lang.Date und SimpleFormatter to produce a String with a date and time information. The translated code uses the CRuntimeJavalike-classes Date etc. Some annotations cause, that only stack-instances and the buffer in the thread context is used, no dynamically memory.

testDateStringDynamic

java.lang.String testDateStringDynamic(java.lang.String sPath,
                                       int ident)

This routine uses the class java.lang.Date und SimpleFormatter to produce a String with a date and time information. The translated code uses the CRuntimeJavalike-classes Date etc. It is the same routine in Java like testDateString(String, int), but there are no annotations. Therefore dynamically memory is used.

testOutStream

void testOutStream(java.lang.String sPath)

testSomeSimpleStringMethods

private int testSomeSimpleStringMethods()

testCharSequence

private void testCharSequence()

A CharSequence is the super-class of java.lang.String and java.lang.StringBuilder. In C it is the same as a StringJc, because the StringJc has the necessary methods and refers a sequence of chars.

The expression CharSequence csq1 = buffer1 is a simple downcast from StringBuilder in Java, but in C it is a toString()-call. The text itself isn't copy thereby, it is referenced. This is the equal functionality. Note that the StringJc is a simple value-struct with reference and length.

testStringProcessing

public java.lang.String testStringProcessing()

Calls the test routines.