Java2C - Requirements and features

Java2C - Requirements and features

Inhalt


1 Features

Topic=.Java2C.Features.

You find a german documentation and discussion above this topic at http://www.vishia.org/Java2C. If you have questions or notes, please mail to hartmut.schorrig@vishia.de.

Why C and not C++?

  • C is nearer to machine code as C++ and therefore better appropriate, if the execution code should be known. It is frequently in embedded control.

  • C is supported for all embedded controller, C++ not in any case.

  • In C the functionality of inheritance and dynamic calls (interface concept) is implementable. Because the translator produces the necessary code, it should not be manually written, the necessary extensive complex statements don't be a problem.

  • In C++ a dynamical call (virtual method call) is unsafe, if any bug had destroyed user data. Because: The reference to the virtual table is a part of user data. In C this problem is better able to control: The informations about a derivated instance type is only able to store in user data. But some additional tests are possible if safety software is required. This tests need some, but not to much calculation time (some nanoseconds on fast processors). Dynamical calls are used often only in slower threads (milliseconds). Therefore C++ will be a inappropriate choice for safety software, C is appropriate.

In the table below the features of the Java2C translator and the CRuntimeJavalike are visualized.

Java-feature

Implementation in C

Remarks

 class MyClass
 { int a;
   MyOther other;
   final int myMethod(...)
   {
   }
 typedef struct MyClass_t
 { ObjectJc object;
   int a;
   struct MyOther_t* other;
   ...
 }MyClass;
 int myMethod_MyClass(...)

ready, basic feature!

 class MyClass extends BaseClass
 { ...
 typedef struct MyClass_t
 { BaseClass super;
   ...

Prio2, inheritance concept is interestedly but not essentially for embedded control. But it is no large expenditure of implementation.

 class MyClass
   implements MyInterface
 { ...
 struct Mtbl_MyClass_t
 { Mtbl_ObjectJc mtblObjectJc;
   { MT_method_MyInterface*
       implMethod;
     ...
 }mtblMyClass
   ...

Prio2, The inheritance concept is interestedly but not essentially for embedded control. It is solved as a matter of principle. An interface is represented by a ObjectJc* reference and a Mtbl-struct (method address table) as part of reflection informations. Searching the appropriate table regards the inheritance tree (base class and interfaces). The reflection of the instance type and the Type of interface/baseclass are used as inputs. No reference to jmp addresses is stored in a data area. It is a concept of safety: A data area may be attacked by a software bug of another module. In such cases no influence to program flow should be exert. To optimize accesses inside a method, the reference to the mtbl is stored in the stack.

 obj.getClass();
 getClass_ObjectJc(obj)

Prio2, The reflection concept is interestedly but not essentially for embedded control. The reflection tables are used to search method tables for the interface concept.

The reflection concept helps inspecting an embedded control system: Using reflections an access to all internal fields and invoking of internal methods can be done from outside without any additional special programming. At example the access can be done via a network interface (UDP).

 class MyClass
 { void myNotFinalMethod(...)
 struct Jtbl_MyClass_t
 { ...

Prio2, It's the same like interface concept, but more simple because a enhanced reference is not need.

 class MyClass
 { ...
   MyClass(...)
   { ref = new OtherClass(args);
 ref = ctor_MyClass
 ( alloc_MemC(sizeof(MyClass))
 , args
 );

ready. The using of dynamic memory is supported both in the construction phase in embedded real-time software and really dynamically at run time. A garbage collector is implemented.

 class MyClass
 { final OtherClass ref
   = new OtherClass(args);
 struct MyStruct
 { ...
   OtherClass ref;
 }
 ...
 ctor_MyClass()
 { ctor_OtherClass
   (&ythis->ref, args
   );

ready. If the reference at class level is final and assigned at class level with the same Class, it is a fix instance. Therefore a embedded struct is realized in C. It is a important basic feature because in C embedded struct are an opportune implementation for nested data.

 ref = new MyClass(args);
 ref = ctor_MyClass
 ( alloc_MemC(sizeof(MyClass))
 , args
 );

ready. In the runtime phase in embedded real-time software no extensively using of dynamic memory should be done. But for special requests like events or temporary Strings, dynamic instances are necessary. To support such, a BlockHeap concept with equals blocks is slated. The dynamic objects should have a limited size. It may be opportune in embedded control.

 Type[] array;
 Type_AY array;

ready. Arrays can be used at C level as referenced arrays. An array pointer type is defined for any type. It contains head information and the data. Such arrays should instanciated dynamically with any length. The head information contains the length of the array.

prio2: Only one-dimensional arrays are implemented yet. More as one dimensions are TODO.

 final Type[] array = new Type[123];
 struct{ ObjectJc object;
         int32 length, ...
         Type data[123]
       } array;

ready. If an Array is fix, it is implemented as embedded instance. The elements of the array may be embedded or referenced. If also the elements are embedded, the array occupies only one memory area inside another struct. It is the commonly used opportune memory model of C programming.

prio2: Only one-dimensional arrays are implemented yet. More as one dimensions are TODO.

 /**@Java2C=simpleArray;*/
 Type[] array = new Type[123];
 Type array[123];

ready. Arrays without any head informations are common used in C. If an algorithm is tested well in Java, and the array itself isn't use as Object in container classes, it can be implemented pure directly like C-programmers knows it. The array.length is translated to a macro ARRAYLEN(array) using sizeof mechanism.

 try{...} catch throw
 STACKTRC_ENTRY("name");
 TRY{...}_TRY
 CATCH(...){...}
 FINALLY{...}
 END_TRY

ready. The try-catch-throw concept is essentially in Java, found in C++ and a convenient and necessary feature in C. The implementation of throw in C is done using the longjmp-concept, known since 1970 and available for all processors. For C++ environments also the try/throw of C++ is useable. See german description at http://www.vishia.org/Jc/html/Exception_Jc.html. There are use some macros to produce a better readable C code. The macros contains simple tests and sets, see ExceptionJc.h.

 String ss = "a" + 5;
 StringJc ss;
 ss = toString_StringBufferJc
      ( iXJc( ...s0BXJc(
      "a"), 5));

ready. Strings are necessary in embedded control to assembly error messages or such ones. The concatenation of Strings is done with a StringBuffer, created in heap memory. The implementation code is not so far readable, but optimal at machine level. It is like Java, no buffer management is to programmed manually. A persistent buffer is able to use also, calling methods of StringBuilder to concatenate. The basic features of java.lang.StringBuilder is implemented.

java.lang.String, java.lang.Thread

ThreadJc, RunnableJc

Prio1. Multithreading is a basic needfull feature of embedded control. Not all features, especially not ThreadGroup etc. are supported.

java.util.List, LinkedList, ArrayList, TreeMap, Container

ListJc, LinkedListJc, ArrayListJc

Prio2. This features are interestedly and supports the reason to work with java. C don't know a good concept of container. All this features are implemented in C level in CRuntimeJavalike. It should be work together with the Garbage-Collector - BlockHeap- concept, because the Nodes of Lists are managed with them.

java.awt, javax.swing

nothing

not supported. If graphical features should be used with Java style, the using of Virtual Machines for Java for embedded controller should be considered. There are some offers, like Jamaica-VM. It is possible to connect C routines with Java at the same processor using JNI or localhost-InterProcessComm or at a second processor. It is a good decision using embedded control in connection with PC based software.

java.net.Socket

InterProcessComm

Prio2. The InterProcessComm is a concept using Socket communication or other communication ways like serial or DualPortRam, above the java.net.Socket-classes. The InterProcessComm may be the basic concept to connect processors with several programming concepts.

java.io

TODO

Prio2. All accesses to the file system are a basic feature in C since anno 1970, but the translation from Java source should be elaborated. As a workaround, use directly C routines to access files and console in special C-written routines.

2 Changes from..to revision

2.1 Changes from 0.81 to 0.82

Topic=.Java2C.changes081_082.

.

2.1.1 Java2C- core

Topic=.Java2C.changes081_082..

The following features are implemented yet and first-time tested with the examples:

  • Implementation of new Type(args) in all expressions, implementation of garbage collection in C.

  • Garbage collection in CRuntimeJavalike implemented and tested.

  • while(){...} do{...}while() and switch(){case:...default: }-statements

  • condition ? exprTrue : exprFalse

  • static members: either simple constants (implemented with define...) or static definition outside the struct-class in C

2.1.2 Detect bugs and requirements

Topic=.Java2C.changes081_082..

  • at ex. Math.abs(): Math should be recognized as class, the Java2C recognized it as unknown reference, an error occurs. Therefore all standard types should be stored in ident lists.

  • for(;;).. is not implemented yet (TODO)

2.1.3 Examples

Topic=.Java2C.changes081_082..

  • The Position-contol-example is completed with a set value generator. A new target position can be setted, it is stored using a new-construction in Java to test the implementation of new and garbage collection in C.

  • A test environment for garbage collection is created.

2.2 Changes from 0.82 to 0.83

Topic=.Java2C.changes083_083.

The version 0.83 is ready now. You can download next versions under http://www.vishia.org/Java2C/sf/Java2C.zip, see also http://www.vishia.org/indexDownload.html.

Date: Sunday, 2009-01-04

2.2.1 Java2C - core

Topic=.Java2C.changes083_083..

The following features are implemented yet and first-time tested with the examples:

  • String processing. The class org/vishia/util/StringPart.java is converted from Java2C and tested.

  • Arrays with 1-dimension. There are some variants of using in C, see Java2C:array-handling.

  • Static methods, static fields.

  • Parameter-sensitive methods (overloaded).

  • try-throw-catch.

  • for, but only the simple variant (not with iterator, Java 5)

  • The org/vishia/util/StringPart.java and StringFormatter.java are classes with String processing, there are translated now in C.

  • Intelligent make process: Using file.stc containing class informations if the file.java is not newer as translated file.c, file.h.

    This concept isn't yet uptodate, because some enhancements in the inner structures. Use only full translation yet.

  • Documentation of java sources.

  • Revision of some data for inner organisation, especially ident and type informations.

  • Implementation of interface routines (dynamic call, virtual methods): It is developted in the first state and tested with the LogMessageFile.java.

  • LogMessage-Output while working garbage collection.

All features are tested with the enclosed example, but not tested hardly.

2.2.2 Examples

Topic=.Java2C.changes083_083..

  • A class ReadTargetFromText.java is created to test the parsing of text inputs at C-level. In the example a list of positions and velocities may be given in text form and parsed at startup time.

  • A concept of a message dispatcher is introduced. The message dispatcher is used as log output by this example, but the logs are adjustable. The org/vishia/util/MsgDispatcher.java is written in java first, than translated to C.

2.2.3 Detect bugs and requirements

Topic=.Java2C.changes083_083..

  • Arrays with more as one dimensions are planned but not full implemented.

  • Partially translation using *.stc-files isn't tested actually.

2.2.4 View to the near future

Topic=.Java2C.changes083_083..

  • The next release should implement the algorithm of dynamic called routines (virtual methods) including the interface concept of java.

  • Working with multiple threads should be the implementation after the interface concept.

  • LinkedList etc. should be implemented in the near future.

  • for-loop-variant using iterator

  • The garbage collector should be tested explicitely.

3 Documentation

Topic=.Java2C.Documentation.

4 Concepts

4.1 Programming concepts

Topic=.Java2C.swConceptsInCentury.

  • 1955: COBOL, Fortran: High level Language Programming

  • 1975: C (Algol, Pascal): Structural Programming

  • 1995: Java (UML): Object Oriented Programming (C++ is not a new concept, only the application of OOP to C with some additional ideas)

  • 2015: commonly using of dynamic programming languages? Functional Programming as new concept after OOP?

All programming language are still in use.

4.2 Differences from C, C++, Java, Solution in Java2C

Topic=.Java2C.CvsJavaImplinJava2C.

topic

C

C++

Java

Solution in Java2C

classes

manually with struct and associated C-routines

basic concept

basic concept

struct and associated C-routines with a fix schema

packages

no, unified global names.

namespaces as possibility of solution (?)

basic concept

definition of alternative C-names of classes (prefix, postfix) to keep unified names.

extension of classes

struct in struct, manually

basic concept

basic concept

struct in struct with a fix schema

interfaces, dynamic call

manually, function-pointer

using class with abstract methods

basic concept

dynamic call tables with a fix schema

common base class for common features of all classes

unknown, manual solutions

unknown, manual solutions

basic concept: Object

basic concept ObjectJc, but it is shrinking useable.

inner classes

manually possible

only classes like static in Java, elsewhere manually

access to outer class without programming effort. Is it a ObjectOriented Conecpt? It is a visibleness concept of nested structures! It is well useable.

implented with outer->

Container

No standard solution, some reuseable libs

The Standard Template Library, but extensively using of dynamical memory, therefore often improperly for embedded solutions.

java.util

LinkedListJc, ArrayListJc, etc. using BlockHeapJc-Concept for fast realtime memory management.

String-processing

zero-terminated strings as basicly idea, sprintf(...), but unsafely because length of strings are unpredictably.

std::string, but extensively using of dynamical memory, therefore often improperly for embedded solutions. Often using of C-concepts with there unsafetyness.

basic concept String, extensively using of dynamical memory while concatenating strings.

StringJc, problem of temorary memory soluted with block heap concept.

dynamic memory

malloc(), but often using static memory because memory leak problem.

new(), memory leak problem is the same like C.

Garbage Collection, managed also the memory segmentation, therefore no memory leaks. But often not for hard realtime.

BlockHeapJc-concept with blocks with same size, only for small data portions (temporary strings, event-data, nodes for LinkedList)

static memory

baisc concept, either malloc() at startup-time or static variables. embedded structs.

same like C

no concept, possible new at startup-time, but not vulgarizes, JTRES: new concept of immortal memory.

same like C, especially support of building of embedded struct on

 Type ref = new Type();

if Type is final.

Orientation of new at startup-time or static memory in C-sources outside Java2C-translated code.

Multi-Threading

No concept, special operation system support necessary

same like C, some special libraries

basic concept, java.lang.Thread, synchronized, Object.wait, java.util.concurrent etc.

basic concept, ThreadJc, ConcurrentLinkedListJc etc., fix os-interface to adapt to any operation system.

4.3 The block heap concept and garbage collection

Topic=.Java2C.BlockHeapConcept.

In hard realtime long-running systems the using of dynamic allocated memory isn't allowed often. The reason is the hazard of appearance of memory leaks. Memory is allocated and freed to any times in any allocated sizes. An algorithm to sort the allocated areas can't be run because it need non interrupted CPU time to work.

But in more complexly algorithms a usage of dynamic memory is desirable. Using Java it is more suggesting to do so. At example:

  • The assembling of a textual output with some informations need a buffer. In C the using of sprintf is a decision. But the buffer should be supplied or existing.

  • Events in a statemachine- or event driven system often needs dynamic allocated memory for itself or for there data.

  • In C or C++ without using dynamic memory a self-made memory management for special cases is implemented often. But this implementations are user specific though it is a system requirement. It is an effort in the users software.

Another topic regarding Java-usage is the garbage collector. A typical C or C++ implementation uses malloc or new and the opposite call of free or delete. But if data are interchanged between modules, one module allocated the memory spaces and another module or more as one another module use it. Which module should delete it?

The answer for Java-like programming with hard realtime long running systems is the BlockHeap-Concept. It combines both requirements, the prevention of memory leaks and the garbage collection.

A base idea is, that a dynamically required memory is not a large memory. All main data should be instantiated statically. Dynamically required data are only small pieces of data: A buffer for textual assembling, a buffer for new event data, or such ones.

4.3.1 Blocks of equal sizes

Topic=.Java2C.BlockHeapConcept..

Therefore the BlockHeap works with blocks with equal size. If any dynamically memory is required, a whole block is occupied. It is not so effective in memory using, but the kilobytes of available memory are not the first problem. In fine tuning there are supported two block sizes: also small blocks inside a normal block, and third a blocksize for nodes of LinkedList, TreeMap etc.

The BlockHeap management are able to instantiate more as one time. Therewith a independent using of blocks is possible. A outreaching usage of blocks from one BlockHeap management instance don't block the other functionality.

4.3.2 The garbage collector

Topic=.Java2C.BlockHeapConcept..

The garbage collector is a basic concept in Java and it should be worked also in C-translated parts. The garbage collector is based on the BlockHeap-Concept.

4.3.2.1 Concept of back references

Topic=.Java2C.BlockHeapConcept...

To detect whether a block of the BlockHeap is used, it should be known if references to it are existing. The Blockheap works with backward references:

From all references to blocks of a BlockHeap backward references are noted inside the appropriate Block of the BlockHeap. By storing a reference the appropriated back reference from the block to the using reference should be set. This work is done by calling

 bool setBackRefJc(ObjectRefValuesJc* refbase, void const* src);

where refbase is the memory address of the reference, from member refbase, and src is the object which is referenced and which is located in any block of any blockheap. The memory address of src needn't be the start of the block, it may an address inside a block. At example it may be a reference to an embedded struct or to a part of a string.

The algorithm of setBackRefJc() detects first, to which heap and to which block in the heap the src is appendant. This is a simple address comparing with all known heaps (there are about 1..10 in a users application) and a simple mask of the address, because each block has a size of power of two. It is possible, that src isn't a reference to a block. Than no action is done.

With knowledge of the correct BlockHeap manager and the block, the back reference to the reference can be set into the block. The setting of back-refs needs a few instruction time, but not much one. In the block there is a array of back references. Typically 1..10 back references can be stored. If there are more, the effort is little more, because the back references need an own block in the Blockheap. But this is not typical. The index of the back reference array element is stored in the enhanced reference, inside the element refbase. So a reference knows, whether and where it has a back reference. It may be also of note in test or debug situations.

If a reference is changed, set to null or removed, the back reference have to be deleted. This work is done by calling

 bool clearBackRefJc(ObjectRefValuesJc* refbase);

Because the index to the back reference is known, this is a fast access.

4.3.2.2 Using the back reference info for garbage collection

Topic=.Java2C.BlockHeapConcept...

The back reference contains the memory address of the reference to the block. The reference may be located in another block of a BlockHeap, or it is a reference from outside. Outside means, it is from static allocated memory, or possible from a reference in the stack. All references are so named enhanced references, containing the reference (pointer in C) and the additional info refbase.

If a reference comes from outside, the block is used!

If a reference comes from another block of a BlockHeap, it comes from inside. That is a dynamically allocated memory location, also to treat by GC. Thereby it is possible that this block is not referenced from anywhere. The garbage collector assembles all blocks that are referencing together, and test them. It is a cluster of blocks. If no outside references to any block of the cluster are found, there are only internal dangling references. The blocks are not in use. This blocks should be freed. In normally, there are a less number of blocks per cluster, 2 or 3... but it is possible it's more.

Abort GC if the referencing situation is changed

But a thread timing effect maybe: At example A and B references it together. B is referenced from outside. The GC recognizes, A is not used from outside, B will be attempted to test.

                  A <----> B <---outside

Now a higher prior thread interrupts the GC, and changes the reference situation to

   outside -----> A <----> B

This is a simple example, but it describes the common situation. If the GC is continued after this operation, the GC thinks, that A is not be used from outside, and recognized yet, that B is also not be referenced from outside. But this is false.

Therefore the garbage collector is aborted in its work if a block is reused with a new or other reference while it is in the testing cluster. The GC should test the blocks of this cluster again, it should forgot the found now assessment. But second, if the same block is tested again, and a fast algorithm switches the references between this blocks again and again, the GC is aborted again and again and it doesn't step forward. Thats why the aborted GC doesn't start with test of the same (aborted) block, it starts in generally with the next block in the BlockHeap.

All tested blocks of a cluster are queued. The queue uses the element nextBlock in the head data of any block. The queue is used and drained, if the whole cluster of blocks is detect as used or free. To implement the behavior of aborting GC, the nextBlock-reference of a new referenced block is tested. If it is not null, the block is member of the current tested cluster. If a setBackref() handle such a block, it set a bit (signal) to the GC to dismiss its work with the cluster.

References from freed blocks: The backward references have to be deleted

A Cluster spans only the block they have references one another. References from internal data of outside blocks are not tested from GC because they are unknown. But backward references may exist from outside to the freeing-candidate blocks. The next figure show it: X and Y are referenced from A and B. X and Y are not tested yet. A is tested first.

       X <--- Y <--- A <---- B

A is referenced from B, but no references from outside are detected furthermore. Therefore A and B builds a cluster and are freed. The result is:

       X <--- Y <--- ?

The question mark symbols a reference to Y inside the old, now freed A.

The backward references in outside blocks to the freeing-candidate blocks should be purged. It is done to set null to inside references. But the user doesn't should be done it at Java level. This action is done in the finalize()-routine of any class. The finalize() is called from garbage collector before freeing the block using dynamic call concept. The finalize_UserType() is generated from Java2C, regarding all references of the UserType. finalize_UserType() contains this generated part of code, plus the part of a possible finalize()-routine from Java level.

4.3.2.3 Optimizations of back-ref-using

Topic=.Java2C.BlockHeapConcept...

Enhanced references with the necessity of call setBackRefJc() are not used

  • for local (stack-) -variables and method arguments,

  • for classes there are not slated for using in dynamically memory, that classes should be marked with @staticInstance in the description of class.

If a reference to a block is only stored in a stack variable without back-reference, it should not be considered by garbage collector to prevent a free of this block while using. Therefore the first (single) using of a block is marked with a bit. If the first back-ref is stored, the block is marked to consider by GC. If no back-reference is stored, the block may be only used locally in a thread. But after its using it should be freed. Therefore on end of the statement block, in which the block is allocated, a call of activateGarbageCollectorAccess_BlockHeapJc() is done to commit it to the GC. After this block either the reference is stored with notation of back-ref, if it is used later again or in another thread, or it is not used furthermore.

But there is a second situation, at example with following Java code:

 void example()
 { Type ref1 = this->ref;
   this->ref = null;
   return ref1;
 }

called by

 Type ref1 = example();
 ref1.dosomething;
 this->ref2 = ref1;

In the 3. line of example() the reference is set to null. It means, the object is not referenced by this->ref. But because the ref1 is not registered as back reference, because it is a stack variable, the GC may free this block, though it is in use. To prevent this situation, there are two solutions:

  • first: The GC should only run, if no other thread is running. It means, it don't interrupt any algorithm. This solution is possible, if a realtime system have only fast threads, there are limited in calculation time. It is typically for time cyclic control algorithms. A system which uses a real Java Virtual Machine for longer processing algorithms, and implements only the fast cyclic parts in C, are a matching example. The GC should run in the lowest thread priority or in a background loop.

  • second: All accesses to the value of a references should be implement the setting of the same bit mConsideredInGarbage_Type_Object in the head data of the block like after a new-statement. All in this manner used blocks should be stored in a list, and should be processed with activateGarbageCollectorAccess_BlockHeapJc() at the end of the visibility of the stack reference. But exclusive that value, which is returned. But this value of block reference should be handled in the stack level above.

The second algorithm is implementable in Java2C-translated sources because the translator knowns all situations. But it needs additional calculation time and it is not optimal for fast control.

There is a third solution:

  • A reference stored as class member should never used only locally, it should be set to null in class member only if the usage of it is excluded. - But this is a request to the programming style.

At this time the first solution is focused. If it is necessary, the third solution can be used. The effort of the second solution should be estimated.

4.3.2.4 Advantage of auto generation

Topic=.Java2C.BlockHeapConcept...

If an concept of garbage collection is used, it don't care which, some special operations should be done. Using C++, automatic generated destructors or overloaded operators can be used. But in C it should be programmed manually. Therefore the automatic code generation from Java to C helps to do this things. The Java2C translator produces the right code without any slips.

4.4 constructor notification

Topic=.Jc_ctor.

.

4.4.1 MemC

Topic=.Jc_MemC.concept.

In the CRuntimeJavalike context a struct MemC {int32 size_; MemAreaC* address;} is defined. It is placed in the header file simpleC.h, because it is not a own concept of CRuntimeJavalike, but an own concept of common C-programming. This struct MemC is an answer about the question: I have a void*-pointer to the memory, but which and how many bytes.... In generally a void*-pointer is a undefined thing. No type is given, no size is known. A void* is a well concept in the C-language with its closure to machine level, but not for user-level programming.

An instance described with MemC is undefined in type, but defined in size. It is a representation of raw memory. An allocation of memory with alloc_MemC(size) returns this struct with the found address and the associated size. It is one parameter for using. Otherwise the size is separated from the void*-pointer and mistakes are possible.

The MemC comprises only 2 register values. Therefore most of C compilers return it in machine level in 2 register, not in a copied struct. It is efficient.

4.4.2 Constructors in C

Topic=.Jc_ctor..

The thinking of constructors cames from Object Orientation. But it is the same as init...-routines in C. Therefore the constructor-concept is used in CRuntimeJavalike and Java2C.

The constructor receives an area of memory and initialized all associated values. Thereby It is possible that references should be initialized, and the memory of this references should be allocated once more and its constructor should be called inside (a new in constructor). But this is a part of the users code.

In C++ the memory for an instance is allocated inside a new ...-expression, and the constructor is called also inside new...-evaluation, but as a extra subroutine. In this constructor-subroutine the pointers to the virtual tables (more as one if the class has base classes) are set. Until after them, the users code is processed.

4.4.3 ctorM-Constructors with MemC in CRuntimeJavalike

Topic=.Jc_ctor..

The constructors are routines, hand written or generated from Java2C-translation, with the general naming image

 ctorM_Type(MemC rawMem, ...);

If more as one constructors are necessary, using C they should be differenced in the name of the subroutine. No argument sensitivity is considered by the compiler. Therefore the name is mutated, at example in form

 ctorM_ii_Type(MemC rawMem, int val1, int val2);
 ctorM_TypeArg_Type(MemC rawMem, TypeArg* ref);

where the argument types are part of the name of the subroutine.

As a parallel to the virtual table initialization in C++, the reference to the reflection_Type-instance is stored in the base-class ObjectJc while the constructor processed.

4.4.4 ctorO-Constructors called in BlockHeap

Topic=.Jc_ctor..

In the BlockHeap, used by Garbage Collection, all instances should be known as ObjectJc. That is neccesary because finalize() have to be called before freeing an instance. It is also opportune to inspect all user data ...who creates dynamically data.... Therefore the ObjectJc-base data are initialized by creating a new block in Blockheap. The rest of construction is done calling a ctorO-Constructor of the users type, with given instance as ObjectJc-reference.

4.4.5 Constructors for C++-using of CRuntimeJavalike

Topic=.Jc_ctor..

The C++-classes in CRuntimeJavalike use the C-struct as base class. C++ is only a wrapper of the functionality, to support better usage. The base principle of usage is:

 class TypeCpp : TypeC
 {
   TypeCpp(args){ ctorc_args_TypeC(this, args); }

The automatic generated machine code of C++-constructor implements the initialization of virtual tables, but the users functionality of construction is still contained in the ctor-Routine of C. In this case the rawMem isn't suppied to the constructor, but the pointer to the struct, It is casted automatically, because the

 ctorc_args_TypeC(TypeC* ythis, args);

is defined as shown. In this case the memory layout is defined, the ythis-type is well defined. The character 'c' is used (ctorc_ instead ctor_) in identifier of the constructor routine. That schema is used in CRuntimeJavalike at all. ctorc-Constructors also initialize the data parts of the ObjectJc-base.

4.5 Parameter sensitive method call in C

Topic=.Java2C.paramSensitivMethodCall.

Methods in Java are parameter sensitive. This feature is known also as overloading of methods. It means, that an method of class StringBuilder

 append(int value)

is another method as

 append(String value).

It is clear for Java users. Okay. In C++ it is the same concept.

But in C, the methods should have an unambiguously name. Therefore, the same steps have to be done which were done from a javac-compiler:

  • Ascertaining the type of all parameters of method call.

  • Searching the appropriate method variant in the environment class, where the method is member of..

  • If no appropriate method is found, variation of the type of parameters to their generalizing types, it means int from short, long from int or float from int etc., but also detect of super classes and interface types of references. Search again.

  • Building the C-like method name considering the parameter types and the environment class name.

This steps are done in Java2C-translation time. The result is visible in the generated C-code. This steps are done only if ambiguously method names are exist. If only unambiguously method names in one class are given, a simple rule is used to build an unambiguously method name common spanned: methodname_classname.

The names of methods considering parameter types should have short, read and understandable by a tester at C-level. For some lang and util-classes the methods have their fix names in the CRuntimeJavalike-C-Library also useable from C-level-programming. The translation of Java method name plus parameter types to that C- method names are given in a translation table. There is no common fix rule to built it. But for method names of the users Java code to translate to C a rule is given.

To visit the precisely steps in the Java2C-translator, visit the javasrc:_org/vishia/java2C/Docu.