org.vishia.java2C
Class Docu.A_InvokationAndEnvironmentConditions

java.lang.Object
  org.vishia.java2C.Docu.A_InvokationAndEnvironmentConditions

Enclosing class:

Docu

public class Docu.A_InvokationAndEnvironmentConditions
extends java.lang.Object

This chapter provides an overview, where and how Java2C should be used.

Docu.A_InvokationAndEnvironmentConditions

public Docu.A_InvokationAndEnvironmentConditions()

A1_applying_goals

void A1_applying_goals()

The writing of sources in Java instead in C or C++ has the advantage, that all features of new programming systems, where Java is a signifying member, can be used for the software development. The programming language C should be recognized as a language for machine-implementing closeness. C isn't the best appropriate language for modern software engineering. At example using UML with C as base language would be a non-effective solution.

The Java2C-Translator allows firstly writing a few sources in Java beside other sources in C, than more and more using Java as source language by recommendation of using UML and Object Oriented technologies. The deciding matter is the usage of a modern software technology. Java2C is only a helper to link this software technology with the classic software development processes.

A2_Java_sources_for_embeddedSoftware

void A2_Java_sources_for_embeddedSoftware()

The Java sources, which can translated to C, are not typical Java applications in a Java-possible environment. For such requirements a Java-virtual machine should be used. If some C- or C++-written parts should be integrated thereby, either the JNI (Java Native Interface) should be used, or some interfaces at example socket connection can be used to connect parts, which runs under Java, with parts, which are written in C(++).

The Java-sources can be conceptualize regarding requirements of embedded programming, which are typical thinking in a C-matter. But it are formulated in the world of Java. At example that is:

• Static data definition instead elaborately using of new Objects: Typical Java applications use the new-operator to define data when it are necessary. The programming is more simple for dynamic tasks, because the data needn't be planned in detail. Last not least the garbage collection concept helps to prevent unnecessary data garbage and to supply the necessary memory space.
  
  But in embedded applications such dynamic memory allocations are undesirable. Therefore a static assessment of all necessary data can be done in Java too, all data should defined in an initial phase. In a UML-thinking they are composition-data than. Java supports the building of compositions with the final keyword on references used together with a new statement:

     final Type data = new Type(initialArguments);
     

  Such data are disposed in C as embedded data. It is possible to define the data in only one memory block, which can instantiated as a static area in the ambient C main-definitions.
• The usage of interfaces is another example. Interfaces are the first way to break dependencies between software modules. The modules can be programmed and tested independently. The exchange of data and control is defined using Java-interfaces. The interfaces can be implemented in some test environment classes to test a module, though they are implemented in the conclusive classes for using. The interface concept is known in UML as a basic concept too.
  
  The usage of interfaces needs a concept of virtual methods (C++-slang). It is either an additional effort to use such, or it is a problem of safety. In C simple prototype declarations of routines are used instead, the implementation of the routines is separated from them, the implementation can be written and test as an independent module too while providing test routines for the linking of a module test for the environment.
  
  Java2C supports using interfaces at Java-level (source-writing, UML) and translating it to simple method calls for the C-implementation level, if the implementation in the target system is defined fix and no polymorphism is need.
• There are some other details too for embedded-like Java-programming, see some examples.

A2_Java_sources_to_translate

void A2_Java_sources_to_translate()

While translation of one Java files all types, which are used there, should be known, a simple plain generation from one Java file to one C-file isn't possible. There are some informations about used types to respect. Therefore either all Java sources which are depending together are translated in one session, or used classes have to be presented with so named stc-files (STruCture of classes). The stc-files were produced from an previous other session of translating of the appropriate sources, or they were translated from header files of manual written C-parts (TODO) respectively hand written. The order of generation depends on the usage of the types. If a type-information is need, the appropriate source is start to translate nested in the current translation. To prevent cyclically dependencies, the translation process is separated in two passes, first and second. The first pass detects all types, the header file thereby, the second pass creates the C-file.

The java sources should be provided in the Java-well-known package structure maybe located at more as one path on file the system (the Java source path for Java2C). All found files are gathered, a tree of known java files is built to declare package and file identifiers. There is an assignment between Java package and file-in-package positions and directories and pre- and suffixes for file names and class (struct-) names at C-side to map the Java-file and class-structure to a C-file and namespace structure. The assignment is given as input for the translater in the config-file.

In the config-file is defined, which sources should be translated, and which sources mustn't translate because there are existent in C either in libraries provided from an extra session or there are existent manually written in C. The Java2C-translator searches the appropriate stc-file for existent C-sources, therefore a stc-search-path is used. The stc-files for several libraries and other C-modules can be dispersed on the file system, adequate to Java-sources.

It is possible that some types are not found as stc-file, because there contain simple methods or data in a simple class. In this case their existence is presumed, and the types of identifiers are accepted as CRuntimeJavalikeClassData.clazz_unknown. Than no additional type conversions are done. The expression with such identifier is submitted in C like found in Java.

A4_invoke_Java2C

void A4_invoke_Java2C()

The invocation of Java2C is command-line-oriented. Some settings are given in a config-file. Some options may be given per command-line argument. In this form the translator is able to embed at example in a ANT-environment of another maker.

• The command line options are explained appropriated to the Java2C.main(String[]).
• The content of config-file is explained appropriated to Java2C_Main#setConfigFile(String). see also Docu.B_ProcessOfTranslation.B3_packageReplacement().
  In the Java2C-supplying bundle hosted at http://sourceforge.net/projects/java2c/ contains examples of usage.